Jon Masters wrote:

On Mon, 2008-11-17 at 12:54 -0900, Jeff Spaleta wrote:

On Mon, Nov 17, 2008 at 12:47 PM, Casey Dahlin <cdahlin@redhat.com> wrote:

Well, 'stable updates' wouldn't apply to F11 for quite a while now.

The proposal is more emotive than actionable so there isn't much to
discuss really.


I disagree. Various other communities (and distributions) have made a
point out of "stable" releases where the "big ticket" feature is
stabilization,


Can you point out such communities and distros and tell us what they
have done?


Rahul

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, Nov 18, 2008 at 5:51 AM, Rahul Sundaram <sundaram@fedoraproject.org> wrote:

Jon Masters wrote:


On Mon, 2008-11-17 at 12:54 -0900, Jeff Spaleta wrote:


On Mon, Nov 17, 2008 at 12:47 PM, Casey Dahlin <cdahlin@redhat.com> wrote:



Well, 'stable updates' wouldn't apply to F11 for quite a while now.


The proposal is more emotive than actionable so there isn't much to

discuss really.




I disagree. Various other communities (and distributions) have made a

point out of "stable" releases where the "big ticket" feature is

stabilization,




Can you point out such communities and distros and tell us what they have done?



Rahul



--

fedora-devel-list mailing list

fedora-devel-list@redhat.com

https://www.redhat.com/mailman/listinfo/fedora-devel-list



Of the top of my head, CentOS and Debian come to mind.* Some might also put Ubuntu LTS and OpenSUSE in that list as well.

Mark Bidewell

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Mark Bidewell wrote:



On Tue, Nov 18, 2008 at 5:51 AM, Rahul Sundaram
<sundaram@fedoraproject.org <mailto:sundaram@fedoraproject.org>> wrote:


Jon Masters wrote:

On Mon, 2008-11-17 at 12:54 -0900, Jeff Spaleta wrote:

On Mon, Nov 17, 2008 at 12:47 PM, Casey Dahlin
<cdahlin@redhat.com <mailto:cdahlin@redhat.com>> wrote:

Well, 'stable updates' wouldn't apply to F11 for
quite a while now.

The proposal is more emotive than actionable so there
isn't much to
discuss really.


I disagree. Various other communities (and distributions) have
made a
point out of "stable" releases where the "big ticket" feature is
stabilization,


Can you point out such communities and distros and tell us what
they have done?

Rahul


--
fedora-devel-list mailing list

fedora-devel-list@redhat.com <mailto:fedora-devel-list@redhat.com>
https://www.redhat.com/mailman/listinfo/fedora-devel-list



Of the top of my head, CentOS and Debian come to mind. Some might
also put Ubuntu LTS and OpenSUSE in that list as well.
I am sorry to say it, but you make a strong confusion between the
targets of different distros.





Mark Bidewell


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, 2008-11-18 at 07:41 +0100, Thorsten Leemhuis wrote:
> On 17.11.2008 23:16, Jon Masters wrote:
> >
> > Various other communities (and distributions) have made a
> > point out of "stable" releases where the "big ticket" feature is
> > stabilization, so I think it would be a win to consider that.
>
> I disagree: It seems to me a lot of the current Fedora users like the
> "latest bells and whistles" style (like you called it in the mail that
> started this discussion) I for one really like the steady stream of
> kernel-updates, as that greatly improves hardware support over time! On
> OpenSuse or Ubuntu you are often forced to run the development branches
> when you need newer driver (just like it was in the early Fedora days
> and in the RHL days).

Indeed, and someone else wants the latest transmission and someone else
the latest pidgin and someone else...
So you either need 100x distributions, or the latest stuff of
everything.

> > I would personally much
> > prefer that stuff that used to work didn't break randomly, and that
> > stable Fedora updates wouldn't result in me wondering whether suspend,
> > graphics, SELinux, or some other feature that was working was going to
> > break today. This isn't actually a rant, more pointing out a necessity.
>
> Agreed, but I tend to say we should work towards a solution where we can
> ship the "latest bells and whistles" and nevertheless provide stability.
>
> I for one think we need something like that:
> https://www.redhat.com/archives/fedora-advisory-board/2008-August/msg00025.html
>
> The relevant part:
>
> """
> I more and more think that we should consider to switch to a more
> rolling release scheme with different usage levels. Roughly something
> like the following maybe:
>
>
> Level 1 -- rawhide, similar to how it is today (a bit more stable and
> less breakage would be nice, but that's in the works already)
>
> Level 2pre -- things that got tested in rawhide, that are still young,
> but known to work well in rawhide; similar to what updates-testing for
> F9 is today;
>
> Level 2 -- things that worked fine for some time in 2pre; similar to
> what F9 is today
>
> Level 3pre -- things that worked fine for some time in 2
>
> Level 3 -- things that worked fine for some time in 2pre
>
>
> Level 3pre and 3 are like F8-updates-testing and F8, but with the
> difference that everything has to be tested and shipped in level 2 (aka
> F9) first.
> """

Ok, the above _only_ works if you can convince all the packagers that
they should backport fixes ... or you end up with things broken in
"Level 2+" until a newer "fixed"¹ package manages to come up through the
levels.

This "rolling relases" is roughly what we do with yum releases now, but
manually and so doesn't have the backport requirements problems. So if
we know that version 123 is pretty good but has a couple of annoying
edge case bugs ... we don't release into Fedora 8. Although even then
sometimes things get through.
If someone thinks there is something magic that can be done to make
releases bug free, they should speak to someone involved in something
that was released into Fedora 9 and will be in RHEL-5.3. I know there
are a couple of packages that did that. It wasn't magic, but it sure
wasn't anything you can easily get people to do for Fedora (IMNSHO).


¹ May contain other bugs.

--
James Antill <james@fedoraproject.org>
Fedora

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

2008/11/18 James Antill <james@fedoraproject.org>:
> On Tue, 2008-11-18 at 07:41 +0100, Thorsten Leemhuis wrote:
>> On 17.11.2008 23:16, Jon Masters wrote:
>> >
>> > Various other communities (and distributions) have made a
>> > point out of "stable" releases where the "big ticket" feature is
>> > stabilization, so I think it would be a win to consider that.
>>
>> I disagree: It seems to me a lot of the current Fedora users like the
>> "latest bells and whistles" style (like you called it in the mail that
>> started this discussion) I for one really like the steady stream of
>> kernel-updates, as that greatly improves hardware support over time! On
>> OpenSuse or Ubuntu you are often forced to run the development branches
>> when you need newer driver (just like it was in the early Fedora days
>> and in the RHL days).
>
> Indeed, and someone else wants the latest transmission and someone else
> the latest pidgin and someone else...
> So you either need 100x distributions, or the latest stuff of
> everything.
>
>> > I would personally much
>> > prefer that stuff that used to work didn't break randomly, and that
>> > stable Fedora updates wouldn't result in me wondering whether suspend,
>> > graphics, SELinux, or some other feature that was working was going to
>> > break today. This isn't actually a rant, more pointing out a necessity.
>>
>> Agreed, but I tend to say we should work towards a solution where we can
>> ship the "latest bells and whistles" and nevertheless provide stability.
>>
>> I for one think we need something like that:
>> https://www.redhat.com/archives/fedora-advisory-board/2008-August/msg00025.html
>>
>> The relevant part:
>>
>> """
>> I more and more think that we should consider to switch to a more
>> rolling release scheme with different usage levels. Roughly something
>> like the following maybe:
>>
>>
>> Level 1 -- rawhide, similar to how it is today (a bit more stable and
>> less breakage would be nice, but that's in the works already)
>>
>> Level 2pre -- things that got tested in rawhide, that are still young,
>> but known to work well in rawhide; similar to what updates-testing for
>> F9 is today;
>>
>> Level 2 -- things that worked fine for some time in 2pre; similar to
>> what F9 is today
>>
>> Level 3pre -- things that worked fine for some time in 2
>>
>> Level 3 -- things that worked fine for some time in 2pre
>>
>>
>> Level 3pre and 3 are like F8-updates-testing and F8, but with the
>> difference that everything has to be tested and shipped in level 2 (aka
>> F9) first.
>> """
>
> Ok, the above _only_ works if you can convince all the packagers that
> they should backport fixes ... or you end up with things broken in
> "Level 2+" until a newer "fixed"¹ package manages to come up through the
> levels.
>
> This "rolling relases" is roughly what we do with yum releases now, but
> manually and so doesn't have the backport requirements problems. So if
> we know that version 123 is pretty good but has a couple of annoying
> edge case bugs ... we don't release into Fedora 8. Although even then
> sometimes things get through.
> If someone thinks there is something magic that can be done to make
> releases bug free, they should speak to someone involved in something
> that was released into Fedora 9 and will be in RHEL-5.3. I know there
> are a couple of packages that did that. It wasn't magic, but it sure
> wasn't anything you can easily get people to do for Fedora (IMNSHO).
>
>
> ¹ May contain other bugs.
>
> --
> James Antill <james@fedoraproject.org>
> Fedora
>
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
maybe these 2 threads should be merged:
1. F11 Proposal: Stabilization
2. Proposal - "Slow updates" repo

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

2008/11/18 Joshua C. <joshuacov@googlemail.com>:
> 2008/11/18 James Antill <james@fedoraproject.org>:
>> On Tue, 2008-11-18 at 07:41 +0100, Thorsten Leemhuis wrote:
>>> On 17.11.2008 23:16, Jon Masters wrote:
>>> >
>>> > Various other communities (and distributions) have made a
>>> > point out of "stable" releases where the "big ticket" feature is
>>> > stabilization, so I think it would be a win to consider that.
>>>
>>> I disagree: It seems to me a lot of the current Fedora users like the
>>> "latest bells and whistles" style (like you called it in the mail that
>>> started this discussion) I for one really like the steady stream of
>>> kernel-updates, as that greatly improves hardware support over time! On
>>> OpenSuse or Ubuntu you are often forced to run the development branches
>>> when you need newer driver (just like it was in the early Fedora days
>>> and in the RHL days).
>>
>> Indeed, and someone else wants the latest transmission and someone else
>> the latest pidgin and someone else...
>> So you either need 100x distributions, or the latest stuff of
>> everything.
>>
>>> > I would personally much
>>> > prefer that stuff that used to work didn't break randomly, and that
>>> > stable Fedora updates wouldn't result in me wondering whether suspend,
>>> > graphics, SELinux, or some other feature that was working was going to
>>> > break today. This isn't actually a rant, more pointing out a necessity.
>>>
>>> Agreed, but I tend to say we should work towards a solution where we can
>>> ship the "latest bells and whistles" and nevertheless provide stability.
>>>
>>> I for one think we need something like that:
>>> https://www.redhat.com/archives/fedora-advisory-board/2008-August/msg00025.html
>>>
>>> The relevant part:
>>>
>>> """
>>> I more and more think that we should consider to switch to a more
>>> rolling release scheme with different usage levels. Roughly something
>>> like the following maybe:
>>>
>>>
>>> Level 1 -- rawhide, similar to how it is today (a bit more stable and
>>> less breakage would be nice, but that's in the works already)
>>>
>>> Level 2pre -- things that got tested in rawhide, that are still young,
>>> but known to work well in rawhide; similar to what updates-testing for
>>> F9 is today;
>>>
>>> Level 2 -- things that worked fine for some time in 2pre; similar to
>>> what F9 is today
>>>
>>> Level 3pre -- things that worked fine for some time in 2
>>>
>>> Level 3 -- things that worked fine for some time in 2pre
>>>
>>>
>>> Level 3pre and 3 are like F8-updates-testing and F8, but with the
>>> difference that everything has to be tested and shipped in level 2 (aka
>>> F9) first.
>>> """
>>
>> Ok, the above _only_ works if you can convince all the packagers that
>> they should backport fixes ... or you end up with things broken in
>> "Level 2+" until a newer "fixed"¹ package manages to come up through the
>> levels.
>>
>> This "rolling relases" is roughly what we do with yum releases now, but
>> manually and so doesn't have the backport requirements problems. So if
>> we know that version 123 is pretty good but has a couple of annoying
>> edge case bugs ... we don't release into Fedora 8. Although even then
>> sometimes things get through.
>> If someone thinks there is something magic that can be done to make
>> releases bug free, they should speak to someone involved in something
>> that was released into Fedora 9 and will be in RHEL-5.3. I know there
>> are a couple of packages that did that. It wasn't magic, but it sure
>> wasn't anything you can easily get people to do for Fedora (IMNSHO).
>>
>>
>> ¹ May contain other bugs.
>>
>> --
>> James Antill <james@fedoraproject.org>
>> Fedora
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
> maybe these 2 threads should be merged:
> 1. F11 Proposal: Stabilization
> 2. Proposal - "Slow updates" repo
>

I like fedora because of the "latest bells and whistles". If
something breaks (and it often does), then it reminds me why i chose
fedora. every new code will always be full of bugs but there are also
other linux distros - (just some of them) opensuse and ubuntu.

this (IMHO) contradicts to the goal of fedora: the "latest bells and whistles".

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Tom "spot" Callaway wrote:

On Mon, 2008-11-17 at 16:35 -0500, Jon Masters wrote:


Yo,

Can I make a proposal for a major theme for an upcoming Fedora (whether
F11 or F12): Stabilization.

Rather than the latest bells and whistles, I would personally much
prefer that stuff that used to work didn't break randomly, and that
stable Fedora updates wouldn't result in me wondering whether suspend,
graphics, SELinux, or some other feature that was working was going to
break today. This isn't actually a rant, more pointing out a necessity.



I'm not sure what magic fairy we'll have to sacrifice for this. We're
always going to be moving forward and things are going to break.

If you're volunteering to help QA, then I applaud you.

~spot




One thing that comes to mind -- Debian style stable, testing, unstable,
and experimental is kind of an interesting policy that gets halfway
there, but it's probably wrong for us. Rather, don't think of those
particular time frames, but the idea of having different levels of
repos. This is closer to Casey's proposal a few threads down.


However he suggests something that might be a bit too close to EPEL --
EPEL doesn't work because a package can easily slip from testing to EPEL
because it's just a monthly roll -- some packages are just a week old
and there is no voting. For some packages, voting would be hard to get.


Perhaps this discussion would be better framed around use cases of
problems it is trying to solve, and then we can find solutions that fit
those use cases:


Use case --- I have no desire to update my desktop, but I want newer
virt tools, and I want security updates.


Use case -- my friend wants newer Open Office but that's it, and doesn't
want to update ImportNetworkThingy until many people say it's ok.


How do we compare against the above already, and how might we take small
actionable steps to get closer to them?


The above use cases almost seems to imply Debian pin priorities, and
that makes me afraid.


Hard problem.

--Michael





--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, 2008-11-18 at 16:07 -0500, Michael DeHaan wrote:
> Use case --- I have no desire to update my desktop, but I want newer
> virt tools, and I want security updates.
>
> Use case -- my friend wants newer Open Office but that's it, and doesn't
> want to update ImportNetworkThingy until many people say it's ok.
>
> How do we compare against the above already, and how might we take small
> actionable steps to get closer to them?
>
> The above use cases almost seems to imply Debian pin priorities, and
> that makes me afraid.
>
> Hard problem.

Couldn't both the above be solved by 'subscribing' to those sets of
packages via say PackageKit? That way when PackageKit goes to look for
updates, it only asks for updates for those particular packages. When
you update, if anything else is needed to satisfy newer builds of those
packages they can be pulled in.

Of course, what we'd likely see is a combo of "Give me all security
updates" and also "Give me updates only for these sets of packages".
The interesting question is how to design UI around the subscriptions.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Jesse Keating wrote:

On Tue, 2008-11-18 at 16:07 -0500, Michael DeHaan wrote:

Use case --- I have no desire to update my desktop, but I want newer
virt tools, and I want security updates.


Use case -- my friend wants newer Open Office but that's it, and doesn't
want to update ImportNetworkThingy until many people say it's ok.


How do we compare against the above already, and how might we take small
actionable steps to get closer to them?


The above use cases almost seems to imply Debian pin priorities, and
that makes me afraid.


Hard problem.



Couldn't both the above be solved by 'subscribing' to those sets of
packages via say PackageKit? That way when PackageKit goes to look for
updates, it only asks for updates for those particular packages. When
you update, if anything else is needed to satisfy newer builds of those
packages they can be pulled in.

Of course, what we'd likely see is a combo of "Give me all security
updates" and also "Give me updates only for these sets of packages".
The interesting question is how to design UI around the subscriptions.




I think I like this.

In the case of "I just want a newer OpenOffice" and don't touch
everything else, that's already covered by a yum install today -- but we
do need something for the update case(s).


--Michael

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, 2008-11-18 at 17:04 -0500, Michael DeHaan wrote:
> > Couldn't both the above be solved by 'subscribing' to those sets of
> > packages via say PackageKit? That way when PackageKit goes to look for
> > updates, it only asks for updates for those particular packages. When
> > you update, if anything else is needed to satisfy newer builds of those
> > packages they can be pulled in.
> >
> > Of course, what we'd likely see is a combo of "Give me all security
> > updates" and also "Give me updates only for these sets of packages".
> > The interesting question is how to design UI around the subscriptions.
> >
> >
>
> I think I like this.
>
> In the case of "I just want a newer OpenOffice" and don't touch
> everything else, that's already covered by a yum install today -- but we
> do need something for the update case(s).

The upside here is that it's purely client side code. We don't have to
change anything about how we prepare and publish updates.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list