Weekly Edition
Return to the Press page
| |||||||||||||
|
| |||||||||||||
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons)
It is well known that Mark Shuttleworth is a proponent of six-month
development cycles. However, in this blog post he
considers the larger changes which cannot be done in six months. "Six-month cycles are great. Now let's talk about meta-cycles: broader release cycles for major work. I'm very interested in a cross-community conversation about this, so will sketch out some ideas and then encourage people from as many different free software communities as possible to comment here. I'll summarise those comments in a follow-up post, which will no doubt be a lot wiser and more insightful than this one :-)"
(Log in to post comments)
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 21, 2009 20:35 UTC (Tue) by allesfresser (guest, #216) [Link] I just want to point out a great idea that was posted as a comment to Mark's article: when doing a long-term release like an Ubuntu LTS, your marketing copy should compare the new release to the previous LTS, not the previous incremental release (e.g., compare 10.04 to 8.04, not to 9.10.) Permalink for comment.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 21, 2009 21:48 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
Red Hat and I assume Novell do this already. Since the long term variants of Fedora and SUSE are branded differently, the material associated with them compare it to their equivalent previous versions. It is a very obvious thing to do.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 22, 2009 17:09 UTC (Wed) by sbergman27 (guest, #10767) [Link]
Well, Fedora/RedHat makes an admin *choose* between "too cavalier to use in a server and still sleep well at night" and "so old and creaky that packages he needs aren't even available anymore". It is highly annoying, but necessary for Red Hat's purposes.
One *really* nice thing about Ubuntu is that when you put a new server into operation, you have the option of using LTS, or if your server hardware is too new to be supported by that, you can use whatever the current release is. The current release is still not intended to be as experimental as Fedora. And has long enough support to get you to the next LTS without an upgrade. Conversely, if you are on LTS and there is some pressing reason to temporarily move to the regular releases to get some feature you need, you can easily do that to, in a supported way.
It's a major advantage. And I'm surprised it doesn't get more attention.
For my customers, Fedora is "too hot", and RHEL is "too cold". But Ubuntu is usually "just right". And if it's not, I can adjust it at any time.
And in that case, it makes sense to make separate comparisons. But it is not immediately obvious that is makes sense to. The extra flexibility that Ubuntu gives to the administrator makes for slightly different strategy when publishing information about it.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 23, 2009 2:36 UTC (Thu) by me@jasonclinton.com (subscriber, #52701) [Link]
FUD. When can we get a moderation system? I'd love to -5 this fanboy.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 23, 2009 19:37 UTC (Thu) by malor (subscriber, #2973) [Link]
He's right -- RHEL is sort of like Debian Stable. It's exceptionally stable, but has old software. There are times when you want stuff that's both newer and auto-updating, so compiling it yourself isn't always an option. In Debian, you can update to Testing or Unstable, but the long release cycles tend to make very large changes between versions, particularly late in a Testing cycle. RHEL, from what I can see (I mostly use Debian) pretty much just goes straight to Fedora (the unstable branch), so there's no interim Testing step. I've used Debian's Testing on production servers in the past, and it's been pretty good, but there's no way I'd use Unstable. Likewise, I suspect trying to run your enterprise database on Fedora is going to be a Bad Idea.
Sbergman is pointing out that, because of the fast release cycles on Ubuntu, going from an LTS to a normal release is a much smaller jump than RHEL->Fedora, and then you can convert it back to the next LTS that ships quite easily, without having to do all that much. This is sort of like Stable->Testing on Debian, but the LTS releases seem to be more frequent, so you end up back at long term stability faster. And the interim stable distros seem prety good... they're just not supported as long as the LTS versions are. (caveat: I haven't used Ubuntu on production servers: I'm assuming they retain most of the Debian quality. This could be wrong.)
I'm not sure you can easily convert a Fedora system back to RHEL... is that even possible? And can you keep yourself patched during the months or years you're running the less stable flavor, without impacting your ability to move to the next long-term version?
BTW, your 'fanboy!' comment is absolutely useless on its own, and is itself deserving of the killfile. There is no signal in your noise. Tell us why he's wrong, include actual useful data, not just that you don't like what he has to say.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 23, 2009 20:16 UTC (Thu) by sbergman27 (guest, #10767) [Link]
"""
I'm not sure you can easily convert a Fedora system back to RHEL... is that even possible? """
It is not supported. But it is possible. It's amusing that the comment above yours accuses me of being a fanboy, as I have extensive experience with all the distros I mentioned. Probably a lot more than he has. After 12 years experience mostly with Red Hat-centric distros, I am admittedly gravitating strongly toward Ubuntu because the advantages are just too substantial for me, as an admin, to ignore.
There are only certain windows of time in which you can convert from Fedora to RHEL/CentOS. The Fedora release that the RHEL version is based upon must be *later* than the version of Fedora you are running. So you have to hang back on your Fedora upgrades and wait the 18-24+ months that it might take for that window to open. (Or even longer, as the RHEL6 cycle demonstrates.)
To make matters more complicated, Fedora releases are dropped like a hot potato 13 months after their initial release. (I've long suspected that the Fedora devs would like to trim that to 0 months if they could only figure out a way to get away with it.) So you *have* to upgrade to maintain security support. RHEL releases lag the Fedora release they are based upon by several months. So it can be a *really* short window of time in which you can both maintain security support *and* be able to do the side-grade to RHEL or CentOS. There is often no time to give the RHEL or CentOS a chance to shake themselves out. You are trusting that they are ready and stable upon release. Which with RHEL/CentOS is usually a pretty good bet.
During that fleeting window of time, you can do a regular RHEL/CentOS upgrade with a boot prompt option whose name eludes me right now. Something like "distro=any". Then when it looks for existing installations to upgrade, it will recognize the Fedora installation and offer to upgrade it.
After the upgrade is complete, you can run:
rpm -qa --last
which shows all the packages in order by their installation dates. Scrutinize the older packages to see if they might be detritus from the old install which can be removed with "rpm -e <packagename>".
And then handle all the little odd lot upgrade problems that are hard to predict. It's usually not too bad.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 23, 2009 21:48 UTC (Thu) by sbergman27 (guest, #10767) [Link]
BTW, the boot string isn't distro=any, as I guessed, above. It is:
linux upgrade any
This was relatively tricky to find in google, even knowing pretty much what I was looking for. So I figured it was worth a quick reply to myself here.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 23, 2009 20:33 UTC (Thu) by me@jasonclinton.com (subscriber, #52701) [Link]
I was bemoaning the lack of a moderation system; not trying to start a debate with an uninformed, ahistorical lunatic. I suggest that you never visit a city in which there are roaming, homeless, crazy people about; I think you'd not be able to make it down the street without stopping to argue with each of them.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 23, 2009 20:38 UTC (Thu) by jordanb (subscriber, #45668) [Link]
LWN doesn't really have a slashdotesque culture to require a "moderation system." If you don't like what someone's said, use your words and disagree with them (and it works better if you come up with decent arguments rather than rely on name calling).
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 23, 2009 20:46 UTC (Thu) by me@jasonclinton.com (subscriber, #52701) [Link]
> LWN doesn't really have a slashdotesque culture to require a "moderation system."
Apparently it does now.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 24, 2009 6:54 UTC (Fri) by hppnq (subscriber, #14462) [Link] Ah, I love the Liar paradox! Thanks!
Re: Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 23, 2009 21:08 UTC (Thu) by nevyn (subscriber, #33129) [Link] RHEL, from what I can see (I mostly use Debian) pretty much just goes straight to Fedora (the unstable branch) That's the kind of thing that the original reply was talking about. You admit you don't know "much" about RHEL/Fedora/etc., as you use Debian. That's fine, you are entitled to your opinion and feel free to talk about what you like. But then when you make arguments based on the assumption that RHEL is the same as Debian Stable (or, ha, Ubuntu LTS) and Fedora is the same as Debian testing ... I just want to "-1, troll" your entire comment.
Re: Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 23, 2009 22:13 UTC (Thu) by malor (subscriber, #2973) [Link]
Well, you could actually, you know, inject some signal and add some facts to your post, instead of just being insulting.
If I'm substantively wrong, I'd be interested to know how. "RHEL = Debian Stable; Fedora = Debian Unstable" both seem to be fair comparisons to me. Do you disagree? If so, why?
Re: Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 24, 2009 6:12 UTC (Fri) by malor (subscriber, #2973) [Link]
Oh, you know, I worded the bit you quoted very poorly, and you might have misunderstood my intent. What I meant was that there doesn't seem to be an interim step between RHEL and Fedora; either you're super stable or super bleeding edge, and forced into constant upgrades with fairly frequent breakage.
That's what I meant by 'goes from' -- the spectrum of stable to unstable appears to have only two major entries on the Redhat side of the fence, where there are three on the Debian side. Debian Testing is sort of a middle ground that blends features from both extremes. And then Ubuntu has even more shades of gray. (from other comments here, those shades may tend toward black... most of the comments don't seem to think much of Ubuntu stability. I'll reserve opinion until I've tried it in a large-scale installation.)
I didn't mean that RHEL turns into Fedora or anything silly like that. And I'm not knocking the distro; I used RH from, geeze, some of their earliest releases, on through to the 7.X series, and I know it's good. I've just come to prefer Debian, because it feels more elegant to me, and I'm quite fond of Ubuntu as a desktop.
Re: Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 24, 2009 17:39 UTC (Fri) by nevyn (subscriber, #33129) [Link] Ahh, ok, I see what you were trying to say. So I'll just mildly disagree :) For instance taking today as a baseline you have (saying this entirely as myself, I do not speak for anyone, etc. etc.):
Now, from what I've seen of debian it has the changes of maybe RHEL-4 (but was branched at a newer point in time). So saying that with the RHEL/Fedora combination you just have a choice of either RHEL-4 or Fedora rawhide is not true. Now Ubuntu seems to be much closer to the old RHL model, which is closer to the change level of Fedora-9 but for it's entire lifetime (but probably not directly comparable). And I think that is a nice advantage, in some ways, but if it's economically viable I'm less sure about. For sure people complain about both the lack of change in even RHEL-5 and the "firehose" of updates in Fedora-10, but almost none of those people are willing to pay money/time to change the available options.
Re: Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 24, 2009 19:31 UTC (Fri) by malor (subscriber, #2973) [Link]
Thanks for the excellent reply, and sorry for the confusing wording in my original post.
I hadn't realized that the continuum was so broad; that's what I get for not tracking RH for so long. It looks like my analogy was, indeed, over-simplified.
From your explanation, I'd say Debian Stable is probably a little behind RHEL5 for content, but has an update policy similar to RHEL3 -- they don't change anything unless it's security- or stability-related. Testing is somewhere between F9 and F10, and Unstable is somewhere between F10 and F11. The nice thing about using Testing is that it becomes Stable like magic, as long as you track by name ('lenny', say, instead of 'testing').
The great-something-grandparent post was pointing out that this same feature applies in Ubuntu -- you can move to a less stable release if you need extra features, and then end up back at a good level of stability before too long, with minimal effort, just by running your updates regularly. The 'granularity', as it were, is very good. It's a nice setup, at least in theory, but it really doesn't sound like others are terribly impressed with their release quality.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 21, 2009 21:46 UTC (Tue) by iabervon (subscriber, #722) [Link]
It seems like the kernel community has a good (and quite different) answer to the question of what to do when your feature can't be done in a single release cycle: target a release several cycles away. Part of this method is based on using a DVCS for your project, so that it's feasible for a developer to say, "I'm starting from 2.6.26, and I'm targeting 2.6.32 for mainline inclusion; here's my repository, anyone who's interested can clone it and send me patches. In ~10 months, I'll have something that people can expect to work, and in ~12 months, we can do the final merge." And there's no need for 2.6.32 to wait for the feature; the merge can just slip to 2.6.33 or something or jump ahead to 2.6.31 if it's ready early.
A release cycle is only constraining with respect to long-term projects if there's something preventing a long-term project from making progress without the incomplete development feeding into the upcoming release.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 21, 2009 23:11 UTC (Tue) by gbutler69 (guest, #54063) [Link]
It's not clear to me how a DVCSS eases these problems for the development of a distribution with Hundres, if not thousands, of independently developed software applications, libraries, and infrastructure, of which, the Kernel is just one part.
I think the challenges are somewhat different and not so easily addressed as your comment would seem to indicate.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 22, 2009 0:31 UTC (Wed) by iabervon (subscriber, #722) [Link]
I was primarily thinking of the development model for each of the individual projects (e.g., GNOME or KDE, or even parts of them), not a distribution, which is a very different sort of project.
But I think that the same fundamental point applies. Ubuntu could decide, today, that Upstart will entirely replace /etc/init.d in April 2010. Package owners could start working on the 10.04 versions of their packages today, and Upstart developers could start looking for problems and conflicts between these packages. Packages that actually have no problems at all could use Upstart in 9.10, but most packages probably would have problems and the 9.10 versions would use the old-style init scripts.
Or possibly Ubuntu wouldn't have a good idea of when a complete system would be able to use exclusively Upstart, so they'd have an Upstart topic branch that's not destined for any particular release. As stuff gets converted and tested, more and more packages get checked off. But until they're all checked off, every release uses the compatibility code for the old style. When everything's checked off, the topic gets merged into the mainline, and the next release drops the old style.
It's not strictly a matter of using a DVCS, but it's a matter of being able to branch and merge effectively.
(I actually have no idea how Upstart is going, but the same principle applies to anything that takes a lot of distribution developer time.)
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 22, 2009 1:27 UTC (Wed) by tzafrir (subscriber, #11501) [Link]
A separate feature branch for upstart?
Now, that translates to a separate packages pool and a separate installation CD. Quite easy to manage, indeed. It doesn't scale.
Furthermore, how do you test upgrading between versions? The more branches you have, the many more testing scenarios you now have.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 22, 2009 2:45 UTC (Wed) by iabervon (subscriber, #722) [Link]
This wouldn't be a general-availability branch, with an installation CD and official package pool and so forth. It would exist exclusively for developing and testing upstart (and packages' upstart scripts), and only be in the version control system. Once it matured to a release candidate state (i.e., it could work as is, but needs testing), it would be merged into the mainline, and only then would there be any (numbered, releasable) version that included its changes.
To be excessively pedantic, every single developer (with any version control system) has their own branch whenever they have uncommitted changes in their working directory. There's a version of the system that has different content from any other version, that diverges from the official main branch. It just doesn't have any infrastructure behind it, and exists only briefly (until the developer gets it committed/merged into the main branch). My point is that it could have a little more infrastructure (a meet point for multiple developers to share related work) and stay in this state for a long time (since it won't get lost with multiple people working on it and the shared location), and this would allow work on some topic to last longer than a release cycle when necessary.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 22, 2009 8:05 UTC (Wed) by epa (subscriber, #39769) [Link] Now, that translates to a separate packages pool and a separate installation CD.Yeah, why not? If this is difficult to manage now (as in the days of CVS, branches of a single project were difficult to manage) then tools can be written to make it easy. The 'upstart' branch or any other feature branch wouldn't be an official release of the distribution, so it would not be necessary to push packages to mirror sites or offer a guaranteed upgrade path.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 22, 2009 19:43 UTC (Wed) by branden (subscriber, #7029) [Link]
Those who fork Debian are condemned to reimplement it.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 22, 2009 23:24 UTC (Wed) by nix (subscriber, #2304) [Link]
Does Debian release as often as that? ;}
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 23, 2009 0:07 UTC (Thu) by sbergman27 (guest, #10767) [Link]
Debian keeps trying, and failing, to implement a 2 year release cycle. And it looks like Red Hat is now failing to live up to the 18-24 month cycle promised for RHEL. Not sure how SLES is doing.
Ubuntu was a little late with their first LTS release, Dapper Drake. But 8.04 came in right on target, as have their regular releases. Good release management planning and discipline, and the ability to say "No", make such predictability possible. As I mentioned in an earlier post, as an admin I'm finding the predictability of schedule for Ubuntu, as well as the seamless migration to/from the LTS and regular releases to be quite attractive and, in fact, a joy.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 23, 2009 8:19 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
I wasn't aware that Red Hat promised any particular release schedule for Red Hat Enterprise Linux. Pointers?
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 23, 2009 20:41 UTC (Thu) by sbergman27 (guest, #10767) [Link]
I find it difficult to believe that you, Rahul, are truly unaware that Red Hat explicitly declared an 18-24 month release cycle for the RHEL product throughout the RHEL2.1 -> RHEL 5.0 time period. (No. I didn't make it up.)
You might have a look around the redhat.com site. But considering the situation with RHEL6, I would expect that they have quietly removed that by this time.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 23, 2009 20:48 UTC (Thu) by sbergman27 (guest, #10767) [Link]
Then again... it might still be on the site:
http://www.redhat.com/f/pdf/rhel/rhel5_overview.pdf
Just search for the numbers 18 or 24.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 23, 2009 16:38 UTC (Thu) by nye (guest, #51576) [Link]
Don't forget a willingness to settle for poor quality. I think that's a major contributing factor in Ubuntu's schedule predictability.
(PS: the line "Debian keeps trying, and failing, to implement a 2 year release cycle" is pure FUD. The Debian project has never made any such claim)
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 23, 2009 19:43 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
What's more, only one Debian release cycle (woody-to-sarge) has ever been longer than 2 years.
Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) Posted Apr 23, 2009 21:40 UTC (Thu) by sbergman27 (guest, #10767) [Link]
Actually, after refreshing my memory a bit... it was 18 months that they were targeting for etch. But some sort of infighting broke and at the last minute. I think they wanted to remove all the firmware from the kernel and impeach their project leader. And so that slipped by 4 months. So 22 months for etch. (Not bad... for Debian.)
For Lenny, they were again targeting 18 months. The last minute infighting was relatively mild this time. But they still missed by 4 months. Again, not too bad... for Debian.
So I probably should have said that they keep trying, and failing, to implement an *18 month* release.
Sorry for any confusion.
At FOSDEM, Stephen commented on a specific target for Squeeze. And I believe the date worked out to about 22 months.
|
|
||||||||||||