- Rawhide
- Meant for the cutting edge of packages. Packages here can be broken regularly so that fixes can be done as fast as possible versus waiting til more expensive times during an adoption curve.
- Release+1 (16)
- A release that will be released soon. Branched from Rawhide and then made into release quality over a 6 month period. Problems and fixes are progressively worked on so that the software is the newest "stable" version.
- Release (15)
- The current "release" which is meant for most users to install and run. Fixes to this release are meant to be neutral. If a newer "stable" version is released it does not mean that it is put into the Current Release but only if no fixes can be made to the version that was released.
- Release-1 (14)
- The release which is nearing its end of life and fixes should only be done for security and critical problems
Ok using the "standard" technology adoption lifecycle, and realizing that Fedora is meant for Innovators and "Early Adopters" versus say people in the Majority curve(**).
- Rawhide should be where people can experiment and break and fix stuff quickly without affecting the main population of users.On the standard technology curve this should be the furthest out innovators and developers.
- Release+1 should be where things are solidifying and innovators are getting things ready for others to use.
- Release should be where innovations have solidified and early adopters can try to make the various parts work for their projects.
- Release-1 is where users who are not ready to move to either Release+1 or Release and may want to jump off to something more "Main Stream" like an Enterprise Linux.
The reality though is that Fedora does not seem to be able to handle this many streams at once. There have been a lot of threads about packages not getting approved for fixes in "Release" and "Release-1" that should have been, and large and long complete breaks in "Rawhide" that have not been fixed. Looking at the threads and in particular Jonathan Corbet's reply to me.
To me the original idea of "No Frozen" rawhide sounded good. I am not sure that the implementation due to the fact that developers can only focus on 1 or 2 releases at any one time. So I think we have problems that need to be addressed after this release.
- Should Rawhide be usable by anyone? If people are using it should they expect any kind of timeframe for problems to be fixed?
- Should we just have a way to move people from rawhide to Release+! when the alpha split occurs and stop updating rawhide til Release+1 becomes Release?
- Should we just give up on the concept of this many releases being available and go for "Release+1, Release, Dooom"?
- With all the other stresses should we just end Fedora on a high note, and move along to "GnomeOS-X" and "NotADesktopOS-X"?
** People who are in the majority parts of the curves prefer items where the cost to adopt is much lower and different than people who are early adopters or innovators. This is why there is such a disconnect between the "Wow this is the greatest thing since sliced bread" and "This is the most horrible change I have ever seen." groups in adoption cycles.
7 comments:
I'm not on fedora-devel, so posting here instead.
I came from a Debian background, where I used to run 'unstable' on my main desktop. As far as I know, there's no real analogue of the Debian package stream, which I think is just 'perfect':
packages first enter 'experimental', bake there for some time, if the package doesn't receive an update for some time, that package then enters 'unstable'. If the package doesn't receive updates for a week more, the package then enters 'testing', which is the Release+1.
Running 'unstable' on Debian was analogous to running Rawhide on Fedora till a while back, when they introduced 'experimental'.
Debian's 'testing' might be what Fedora's Release+1 is, after the branch, but even then, the package stream in Debian isn't mirrored in Fedora, as shown by the email thread you started: packages can enter updates-testing without entering Rawhide at all, in cases.
This doesn't generally follow the 'upstream first' policy, where we try to backport a patch to Release only if Relase+1 has the patch. Enforcing this might encourage a proper stream.
There are urgent cases, like security updates, where packages could be updated in multiple releases simultaneously, but again, never in a stable release without a corresponding update in a newer release.
This, really, is one of my biggest grouses in Fedora, that keeps me fairly away from the real 'bleeding edge'.
I'm not on fedora-devel, so posting here instead.
I came from a Debian background, where I used to run 'unstable' on my main desktop. As far as I know, there's no real analogue of the Debian package stream, which I think is just 'perfect':
packages first enter 'experimental', bake there for some time, if the package doesn't receive an update for some time, that package then enters 'unstable'. If the package doesn't receive updates for a week more, the package then enters 'testing', which is the Release+1.
Running 'unstable' on Debian was analogous to running Rawhide on Fedora till a while back, when they introduced 'experimental'.
Debian's 'testing' might be what Fedora's Release+1 is, after the branch, but even then, the package stream in Debian isn't mirrored in Fedora, as shown by the email thread you started: packages can enter updates-testing without entering Rawhide at all, in cases.
This doesn't generally follow the 'upstream first' policy, where we try to backport a patch to Release only if Relase+1 has the patch. Enforcing this might encourage a proper stream.
There are urgent cases, like security updates, where packages could be updated in multiple releases simultaneously, but again, never in a stable release without a corresponding update in a newer release.
This, really, is one of my biggest grouses in Fedora, that keeps me fairly away from the real 'bleeding edge'.
Debian has a rolling release of their development releases available to anyone, and I was glad when not too long ago Fedora also made Rawhide a rolling release. I used Rawhide before it was a rolling release, and it was a pain to switch releases back and forth every few months. I think there would be more new testers like me if Rawhide was kept a rolling release available to anyone.
I think Rawhide should be broken more often so that recent breaks like grub2 in Fedora 16 Alpha happen less. Sometimes it seems like Fedora updates-testing is too similar to Rawhide. And no, I don't expect anything in Rawhide to be fixed quickly, (or even an announcement that it is broken) but it's usually already fixed, just the mirrors haven't caught up yet.
I like that Rawhide is available to anyone, since I really didn't learn much about Linux until running Rawhide where things are sometimes broken. It's also easier for new users like me to try and contribute back and submit bugs early on Rawhide's broken packages.
Debian has a rolling release of their development releases available to anyone, and I was glad when not too long ago Fedora also made Rawhide a rolling release. I used Rawhide before it was a rolling release, and it was a pain to switch releases back and forth every few months. I think there would be more new testers like me if Rawhide was kept a rolling release.
I think Rawhide should be broken more often so that recent breaks like grub2 in Fedora 16 Alpha happen less. Sometimes it seems like Fedora updates-testing is too similar to Rawhide. And no, I don't expect anything in Rawhide to be fixed quickly, (or even an announcement that it is broken) but it's usually already fixed, just the mirrors haven't caught up yet.
I like that Rawhide is available to anyone, since I really didn't learn much about Linux until running Rawhide where things are sometimes broken. It's also easier for new users like me to try and contribute and submit bugs early on Rawhide's broken packages.
Maintaining multiple versions used to work fine before FESCo started enforcing completely unrealistic QA requirements through automated and inflexible tools. We just need to go back to letting the maintainers maintain their packages and updates in releases will flow again.
As for Rawhide, it was never intended to be used in production, it's normal if it doesn't work. This was already the case before No Frozen Rawhide.
Since Debian comes up a lot as the salient comparison.
If we are going to look at Debian as a comparison, then it would be extremely useful for us to have a deeper understanding of the the role testing and unstable branches in Debian play and how they are being used and what the pain points are. There's a move afoot to add yet another stream inbetween unstable and testing called "cuts" continuously upgradable testing.
I have several questions concerning the seasonal (in the release cycle sense) of migratory behavior patterns concerning how Debian users self-select.
I do have concerns that our time based release schedule puts a resource constraint on us that makes it very difficult for individuals to focus on multiple streams. A noteworthy constraint missing in the Debian comparison. I can't speak for anyone else but I know I'm underwater with regard to my Fedora packaging(due primarily to some changes in the role I play in my dayjob)
If we had a way to track (in aggregate) work output in each of the branches maybe we could get a clearer picture of the effect no frozen rawhide policy change impacted workflow project wide. I just don't know how'd you get that metric. Git/CVS activity across all packages lumped into weekly activity number?
-jef
Just to register my standard vote again, I don't think the current release system suits what we're actually trying to do with fedora at all, and leads to a lot of unnecessary work. I'd much prefer a streamlined debian-style rolling release system, to reduce a lot of the burden imposed on development and qa by supporting (in a fairly half assed way) so many streams.
Of course, ironically, I never get around to proposing this formally as I'm too busy doing karma for F14...sigh.
Post a Comment