Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On Thu, Nov 25, 2010 at 01:18:54AM -0500, Genes MailLists wrote: On 11/25/2010 01:13 AM, Genes MailLists wrote: http://oswatershed.org/ Hmm some interesting data there and some looks wrong to me: I see openssh at 5.5p1 not 5.0p1. but some like apache ours is lagging by quite a bit ... Did you email him to correct the openssh error? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On 11/22/2010 09:44 AM, Genes MailLists wrote: 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. 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. (ii) Staging (or updates testing :-) * Also - seems staging may want/need a appropriate time limited freeze period for final testing before the updates get moved to stable. .. I see Ubuntu is moving this way as well http://www.theregister.co.uk/2010/11/23/darily_ubuntu_updates/ Not that we should do what they do ... :-) But this may be a more resource efficient model for fedora. I think it would be really good for the experienced here to help flush this out and come up with a solid model ... gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On 11/22/2010 01:23 PM, Genes MailLists wrote: On 11/22/2010 09:44 AM, Genes MailLists wrote: ... rolling releases ... Interesting website - may be useful in thinking about the release cycle ... or not :-) http://oswatershed.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On 11/25/2010 01:13 AM, Genes MailLists wrote: On 11/22/2010 01:23 PM, Genes MailLists wrote: On 11/22/2010 09:44 AM, Genes MailLists wrote: ... rolling releases ... Interesting website - may be useful in thinking about the release cycle ... or not :-) http://oswatershed.org/ Hmm some interesting data there and some looks wrong to me: I see openssh at 5.5p1 not 5.0p1. but some like apache ours is lagging by quite a bit ... Current (14) Package Version RevisionUpstream VersionNumber NewerLag NetworkManager 0.8.1 0.8.2 4 8w alsa-utils 1.0.23 1.0.23 0 ✔ cups1.4.4 1.4.5 1 1w emacs 2 3.2 23.20 ✔ firefox 4.0 4.0b7 14 21w gcc 4.5.1 4.5.1 0 ✔ ghostscript 9.009.000 ✔ gimp2.6.11 2.7.1 0 ✔ glibc 2.12.90 2.12.1 0 ✔ gnome-desktop 2.32.0 2.91.2 4 7w gnupg 2.0.16 2.0.16 0 ✔ httpd 2.2.17 2.3.6 1 22w kdebase 4.5.3 4.5.77svn11987041 5d linux 2.6.36 2.6.37-rc3 4 3w openssh 5.0p1 5.6 6 122w pidgin 2.7.5 2.7.7 2 2d postgresql 8.4.5 9.0.1 2 7w python 3.2 3.2a4 4 16w ruby1.8.7.302 1.9.2-p01 14w xorg-server 1.9.1 1.9.2.901 2 3w -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
Adam Williamson wrote: On Mon, 2010-11-22 at 10:21 +0100, Hans de Goede wrote: 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). It's not how we used to work (F9, F10, F11 got 2 KDE rebases each), nor how I think we SHOULD work (I think Fn-1 shouldn't be getting second-class support, what we did for F9-F11 was the right thing!), but how we ended up working for F12 (mainly because 4.5 took forever to test, so F12 was almost EOL when we declared it stable) and how we're probably going to work now (assuming they'll even let us do the one KDE rebase), due to all the anti-upgrade pressures. :-( 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. Uh, you just explained yourself why it's not! (People don't like it stable, they're just too lazy to upgrade.) 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 :) It's a very bad idea, it'll lead to even more people running unsupported Fedora releases. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On Tue, 2010-11-23 at 18:32 +0100, Kevin Kofler wrote: 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. Uh, you just explained yourself why it's not! (People don't like it stable, they're just too lazy to upgrade.) What I thought was a good point is that our professed reason for the twelve month cycle is to allow users to 'skip a release', but that in practice this is tricky because it requires you to upgrade very early in the life of a new release, which historically speaking is not the most stable point. -- 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
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On 11/23/10 12:16 PM, Toshio Kuratomi wrote: On Mon, Nov 22, 2010 at 11:39:02AM -0800, Jesse Keating wrote: 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. I'd say that people like this probably want to start installing Fedora at the point where no reversions of major Features are likely to occur. So they probably want to do their initial install at a point in the process after Alpha. I don't know where we match up though... the systemd reversion was a bit of a mess and I don't know how the process is supposed to work as opposed to how it did work this time around. -Toshio Alpha is post-feature freeze, so there shouldn't be reversions of features after that point, outside of special cases. systemd was a special case. If we as a project stuck better to our feature freeze and process, then installing from Alpha would be a more favorable target. -- 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
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On Mon, Nov 22, 2010 at 12:39, Jesse Keating jkeat...@redhat.com wrote: 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. It sounds like it.. but psychologically is a completely different thing. Alpha/beta/rawhide all sound too scary and they won't go near it. However when they finally get on an RC or release they will go through the same steps that the alpha/beta/rawhide/ or -testers users had to do. Which then leads to a lot of stuff getting rolled in at the last minute. I just don't think Slow and Stable is ever going to work with Fedora. -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Let us be kind, one to another, for most of us are fighting a hard battle. -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora release model (was Re: 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
Re: Fedora release model (was Re: 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
Re: Fedora release model (was Re: 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
Re: Fedora release model (was Re: 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
Re: Fedora release model (was Re: 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
Re: Fedora release model (was Re: 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
Re: Fedora release model (was Re: 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
Re: Fedora release model (was Re: 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 pgpBu5vZcWUjk.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: 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
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On Mon, Nov 22, 2010 at 8:15 PM, mike cloaked mike.cloa...@gmail.com wrote: On Mon, Nov 22, 2010 at 6:59 PM, Adam Williamson awill...@redhat.com wrote: 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 ? During the runup period to F14 release I published a method for taking an iso and replacing the anaconda in the iso - which can then be used for a test install. This is detailed in a posting around a month before f14 GA if you want to check it out. This would certainly be a way to test anaconda with all other components unchanged but it does need a current iso to be built on the current package set. My original post is at http://lists.fedoraproject.org/pipermail/test/2010-October/094752.html if you are interested. -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
