FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 11-22-2010, 08:21 AM
Hans de Goede
 
Default Fedora release model (was Plan for tomorrow's FESCo meeting (2010-11-17))

Hi,

On 11/22/2010 12:59 AM, Adam Williamson wrote:
> On Sun, 2010-11-21 at 23:04 +0100, Kevin Kofler wrote:
>
>> In short: Want higher-quality updates for previous releases? Then push
>> version upgrades wherever possible (even and especially for libraries, as
>> long as they're ABI-compatible or can be group-pushed with a small set of
>> rebuilt reverse dependencies)!
>
> I don't agree with this at all. It's just abusing a stable release cycle
> to try and make it into something it isn't.
>
> I should probably clarify where I'm coming from on this, as my position
> is probably more nuanced than my mails so far would seem to suggest. I
> don't necessarily think Fedora works best as a project which does stable
> releases every six months and supports at least two of them at a time
> (and often three). As I've written elsewhere, I'd very much like to look
> into the possibility of changing that.
>

<snip>

> It seems like what you want is actually not to have three releases at a
> time at all but to have one and update it constantly. And I actually
> rather suspect that would be a model that would work well for Fedora,
> and I'd like to look into adopting it.

Interesting topic (much more so then flaming about the updates policy)
I think that we can (and sort of do already) have both.

The way I see it, is we have:

rawhide (and for a part of the cycle Fedora #+1 testing)
Fedora #
Fedora #-1
Fedora #-2

Fedora #+1 is for people who want the bleeding edge
Fedora # is for people who want the latest and greatest without too much
bleeding
Fedora #-1 is for people who want it relatively safe and slow
Fedora #-2 Does not fit into this picture

So taking for example the much much discussed KDE rebases. I think that
doing a KDE rebase for Fedora #+1 is a no brainer, for Fedora # is fine
as long as it is properly tested and for Fedora #-1 KDE should NOT be
rebased. This also matches well with what the KDE people have been
reporting, were they can get plenty of testing on Fedora # but all most
none on Fedora #-1. I think that the few KDE users which remain on
Fedora #-1, do so because they appreciate some stability, and thus
should not get (a largely untested) KDE rebase.

This is also how I in practice deal with must updates for packages I
maintain I try to fix any serious bugs reported against Fedora # and am
a lot more conservative when it comes to Fedora #-1.

Note that Fedora #-2 does not fit into this view for things at all,
Fedora #-2 is meant to allow people to skip a Fedora release. But in
practice I think this works out badly, because a relatively new Fedora
release like Fedora 14 tends to still have some rough edges and get lots
of updates/churn (and thus possible regressions, despite our best effords).
This is not at a good point in its cycle to upgrade to for people who like
it stable (and sticking with 1 release for an entire year to me sounds
like liking it stable).

Where as the one which has already been out for 5-6 months (Fedora 13) has
seen most rough edges polished away with updates, and the updates rate will
have slowed.

So maybe it is time we dropped the support duration for a release from 13
to 11 months, and make clear that people should not skip releases.

Regards,

Hans
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-22-2010, 01:44 PM
Genes MailLists
 
Default Fedora release model (was Plan for tomorrow's FESCo meeting (2010-11-17))

On 11/22/2010 04:21 AM, Hans de Goede wrote:
> Hi,
>
> On 11/22/2010 12:59 AM, Adam Williamson wrote:


>> It seems like what you want is actually not to have three releases at a
>> time at all but to have one and update it constantly. And I actually
>> rather suspect that would be a model that would work well for Fedora,
>> and I'd like to look into adopting it.


>
> The way I see it, is we have:
>
> rawhide (and for a part of the cycle Fedora #+1 testing)
> Fedora #
> Fedora #-1
> Fedora #-2
>


I agree with the idea of a rolling release model - however I think we
need to tune it for our needs - I think of it more closely to the kernel
development model but not the same - we have a distro not a kernel.



(i) Stable - Fedora M.n (e.g. 14.0)
What normal users run.


(ii) Staging (or updates testing :-)
Staging-Security.

* This is the staging area for collections that are
deemed worthy of rolling into stable after some
wider testing.

* Security updates should be in a separate security-staging
repo.

* Whenever we move a bunch of packages from staging to
stable we raise the minor number to M.(n+1). Larger
changes may require major number bump if deemed
appropriate (e.g. systemd, kde 8.0, gnome 3 and
occasionally a kernel update)

* Maintainers required to test reasonably anything that hits
staging - not on all platforms or in all configs but as
many as they can reasonably.

* We keep iso file of current major (M.n) and prior major for
install purposes (M-1.x)


(iii) Development - (aka rawhide)

* These should be tested by pulling packages into current
stable or staging - just as they would be after they get
moved to staging. This is definitely not a separate install,
but add-on packages to staging/stable.


gene/




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-22-2010, 03:18 PM
Adam Williamson
 
Default Fedora release model (was Plan for tomorrow's FESCo meeting (2010-11-17))

On Mon, 2010-11-22 at 10:21 +0100, Hans de Goede wrote:

> The way I see it, is we have:
>
> rawhide (and for a part of the cycle Fedora #+1 testing)
> Fedora #
> Fedora #-1
> Fedora #-2
>
> Fedora #+1 is for people who want the bleeding edge
> Fedora # is for people who want the latest and greatest without too much
> bleeding
> Fedora #-1 is for people who want it relatively safe and slow
> Fedora #-2 Does not fit into this picture

Quite a few people take this view, but I'm not sure it's entirely
reliable. As I see it there may well be those who use the system as you
suggest - they upgrade every six months but to the *last* release, not
the current one, so they're always running F#-1 - but I'm fairly sure
there's also those who actually use the current lifecycle system for its
stated purpose, which isn't to allow you to constantly run one version
out of date, but to run each version for up to twelve months. So they
ran F8, then F10, then F12, then F14 - skipping 9, 11 and 13 so they
only have to deal with the pain of an update every 12 months. To these
types of users, it doesn't necessarily make sense to treat a -1 release
differently from a 'current' release.

> So taking for example the much much discussed KDE rebases. I think that
> doing a KDE rebase for Fedora #+1 is a no brainer, for Fedora # is fine
> as long as it is properly tested and for Fedora #-1 KDE should NOT be
> rebased. This also matches well with what the KDE people have been
> reporting, were they can get plenty of testing on Fedora # but all most
> none on Fedora #-1. I think that the few KDE users which remain on
> Fedora #-1, do so because they appreciate some stability, and thus
> should not get (a largely untested) KDE rebase.

I hope I'm not putting words in KK's mouth again , but I believe this
is actually more or less what KDE team does; the current KDE update
isn't a rebase as far as they see it, it's a minor point update. I think
they may well not push KDE 4.6 to F13 when it comes out, but only to
F14. (Yell at me again if I'm wrong, KK).

> This is also how I in practice deal with must updates for packages I
> maintain I try to fix any serious bugs reported against Fedora # and am
> a lot more conservative when it comes to Fedora #-1.
>
> Note that Fedora #-2 does not fit into this view for things at all,
> Fedora #-2 is meant to allow people to skip a Fedora release. But in
> practice I think this works out badly, because a relatively new Fedora
> release like Fedora 14 tends to still have some rough edges and get lots
> of updates/churn (and thus possible regressions, despite our best effords).
> This is not at a good point in its cycle to upgrade to for people who like
> it stable (and sticking with 1 release for an entire year to me sounds
> like liking it stable).

That's a reasonable point indeed.

> Where as the one which has already been out for 5-6 months (Fedora 13) has
> seen most rough edges polished away with updates, and the updates rate will
> have slowed.
>
> So maybe it is time we dropped the support duration for a release from 13
> to 11 months, and make clear that people should not skip releases.

That's one I didn't have on my list of ideas to look at; I'll add it
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-22-2010, 05:23 PM
Genes MailLists
 
Default Fedora release model (was Plan for tomorrow's FESCo meeting (2010-11-17))

On 11/22/2010 09:44 AM, Genes MailLists wrote:

> repo.
>
> * Whenever we move a bunch of packages from staging to
> stable we raise the minor number to M.(n+1). Larger
> changes may require major number bump if deemed
> appropriate (e.g. systemd, kde 8.0, gnome 3 and
> occasionally a kernel update)
>


Need in addition -


* Any major version increase must be verified to be
installable from the ISO.


* A major version should be imposed every 6 months if it
has not for some reason.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-22-2010, 05:35 PM
Adam Williamson
 
Default Fedora release model (was Plan for tomorrow's FESCo meeting (2010-11-17))

On Mon, 2010-11-22 at 13:23 -0500, Genes MailLists wrote:

> * A major version should be imposed every 6 months if it
> has not for some reason.

Why? Your idea of tying version bumps to actual changes in the product
rather than an arbitrary timeline is an interesting one, but then having
a backstop forced version bump every six months even if there is no
relevant change completely undercuts the idea.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-22-2010, 05:47 PM
Genes MailLists
 
Default Fedora release model (was Plan for tomorrow's FESCo meeting (2010-11-17))

On 11/22/2010 01:35 PM, Adam Williamson wrote:
> On Mon, 2010-11-22 at 13:23 -0500, Genes MailLists wrote:
>
>> * A major version should be imposed every 6 months if it
>> has not for some reason.
>
> Why? Your idea of tying version bumps to actual changes in the product
> rather than an arbitrary timeline is an interesting one, but then having
> a backstop forced version bump every six months even if there is no
> relevant change completely undercuts the idea.


Good point ... was thinking it was a way to ensure anaconda keeps
pace but you're right ... it should follow the actual changes ...

Do you have any suggestions how to manage ensuring that each ISO
snapshot has a working anaconda ?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-22-2010, 05:59 PM
Adam Williamson
 
Default Fedora release model (was Plan for tomorrow's FESCo meeting (2010-11-17))

On Mon, 2010-11-22 at 13:47 -0500, Genes MailLists wrote:
> On 11/22/2010 01:35 PM, Adam Williamson wrote:
> > On Mon, 2010-11-22 at 13:23 -0500, Genes MailLists wrote:
> >
> >> * A major version should be imposed every 6 months if it
> >> has not for some reason.
> >
> > Why? Your idea of tying version bumps to actual changes in the product
> > rather than an arbitrary timeline is an interesting one, but then having
> > a backstop forced version bump every six months even if there is no
> > relevant change completely undercuts the idea.
>
>
> Good point ... was thinking it was a way to ensure anaconda keeps
> pace but you're right ... it should follow the actual changes ...
>
> Do you have any suggestions how to manage ensuring that each ISO
> snapshot has a working anaconda ?

This is the kind of thing automated testing would help a lot with; we
already have some automated testing of anaconda in place, but it doesn't
cover many paths, only the most basic - essentially it 'clicks through'
anaconda with a very basic hardware setup and checks it can complete.

right now the only way to do it would be to run the automated testing as
often as possible to catch basic breakage, and the manual installation
validation test suite (done by the qa group members) on each ISO
snapshot.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-22-2010, 06:06 PM
Genes MailLists
 
Default Fedora release model (was Plan for tomorrow's FESCo meeting (2010-11-17))

On 11/22/2010 01:59 PM, Adam Williamson wrote:
>> Do you have any suggestions how to manage ensuring that each ISO
>> snapshot has a working anaconda ?
>
> This is the kind of thing automated testing would help a lot with; we
> already have some automated testing of anaconda in place, but it doesn't
> cover many paths, only the most basic - essentially it 'clicks through'
> anaconda with a very basic hardware setup and checks it can complete.
>
> right now the only way to do it would be to run the automated testing as
> often as possible to catch basic breakage, and the manual installation
> validation test suite (done by the qa group members) on each ISO
> snapshot.


Perhaps this can be helped by putting the staging area into a short
term freeze prior to things going to stable and make the ISO snapshot
available at that time (or maybe it should be rebuilt nightly as well do
you think?)

That would give a chance for auto-qa as you described as well as
normal testers who may want to test a clean install from the snapshot.

gene/


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-22-2010, 06:18 PM
Toshio Kuratomi
 
Default Fedora release model (was Plan for tomorrow's FESCo meeting (2010-11-17))

On Mon, Nov 22, 2010 at 08:18:04AM -0800, Adam Williamson wrote:
> On Mon, 2010-11-22 at 10:21 +0100, Hans de Goede wrote:
>
> > The way I see it, is we have:
> >
> > rawhide (and for a part of the cycle Fedora #+1 testing)
> > Fedora #
> > Fedora #-1
> > Fedora #-2
> >
> > Fedora #+1 is for people who want the bleeding edge
> > Fedora # is for people who want the latest and greatest without too much
> > bleeding
> > Fedora #-1 is for people who want it relatively safe and slow
> > Fedora #-2 Does not fit into this picture
>
> Quite a few people take this view, but I'm not sure it's entirely
> reliable. As I see it there may well be those who use the system as you
> suggest - they upgrade every six months but to the *last* release, not
> the current one, so they're always running F#-1 - but I'm fairly sure
> there's also those who actually use the current lifecycle system for its
> stated purpose, which isn't to allow you to constantly run one version
> out of date, but to run each version for up to twelve months. So they
> ran F8, then F10, then F12, then F14 - skipping 9, 11 and 13 so they
> only have to deal with the pain of an update every 12 months. To these
> types of users, it doesn't necessarily make sense to treat a -1 release
> differently from a 'current' release.
>
Note that by and large I agree with the combination of Hans's post (what
I wishfully would like Fedora's update policy to be) and yours (that
currently to various different people it's one of what Hans posts or an
opportunity to skip a release or a no-big-updates-once-released all around).

I'd just like to point out in response to this paragraph that a few people
have posted that they appreciate both an initial rolling release style and
a 13 month release cycle. They said that they install a Fedora for testing
purposes when it first comes out and enjoy the rapid pace of bugfixes as
they test the software in their environment. Then, the update pace slows
down at about the same time their ready to push things out to the machines
in their env.

I think there's likely better ways that they could achieve this if we were
optimizing for this, though.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-22-2010, 06:39 PM
Jesse Keating
 
Default Fedora release model (was Plan for tomorrow's FESCo meeting (2010-11-17))

On 11/22/2010 11:18 AM, Toshio Kuratomi wrote:
> They said that they install a Fedora for testing
> purposes when it first comes out and enjoy the rapid pace of bugfixes as
> they test the software in their environment. Then, the update pace slows
> down at about the same time their ready to push things out to the machines
> in their env.
>
> I think there's likely better ways that they could achieve this if we were
> optimizing for this, though.
>


This sounds like "install the newly Branched release (AKA Alpha)", which
has rapid updates, but should slow down once it goes GOLD, and then be
slow and stable for the next 13 months after that.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 07:27 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org