Robert has posted his thoughts, mostly a summary of Mark Shuttleworth's talk at a past Akademy, about 6 month release cycles. It's an interesting read and worth taking the time to do so.
Unfortunately, Mark's presentation was simply full of the same unfounded or just plain ridiculous assertions that Mark is fond of making in public these days. Let's take a few of them:
"Regular, predictable releases which are synced with appropriate other projects provide a sense of rhythm and structure."
To whom? And to what end? It turns out that this rhythm is mostly to downstream, and the structure is completely based on the sense of perception not anything concrete. We can provide for downstream's desire for rhythm, but we don't need to harmonize release cycles with every other "appropriate" project.
It would be like going into a large company that makes hundreds of different products with a loose common theme (ours is software; Lockheed-Martin would be aerospace; GE would be anything that attempts to make money ;) to sync up all those product cycles. Not only is it ridiculously expensive to do so, it just doesn't add up to anything meaningful production wise.
This is the classic mistaking of "what I want translates to what you do". I completely am on side with providing downstream with what works for them, but at the expense of our productivity? Nope. Thankfully I think we can have both.
"It allows projects up/down and across-stream to plan better and co-operate more efficiently."
I've yet to see any evidence for this.
Let's assume project A depends on B, and B releases at the same time as A. That means that A is either going to be one cycle behind B in using what B provides, or will have to track B's bleeding edge for the latter part of their cycle allowing some usage. What you really want is a staggered approach where B releases right about when A starts to work on things.
This goes completely counter to the "everyone on the same month, every 6 months" doctrine Mark preaches, of course.
If A and B are orthogonal, then who cares. There is no cooperation to be had. Unless, of course, you are a downstream integrator wanting new features across the board on every release. I don't think that's really what the mass market wants or cares about, but it's useful to recognize the real drive behind this: it isn't software development, it's software integration for a very specific set of people.
"If distributors believe they can trust KDE's release schedule and release quality then they will allow a smaller safety margin between the time KDE makes a release and the time when distributors need to ship their next release."
The implied statement here is that distributors can't trust KDE if there isn't a set cycle. History proves this one wrong on its face, both in the general sense (last time I checked Oracle, SAP, Microsoft, etc.. didn't do this) and in the specific sense (lots of trust in KDE out there). So this one rubs me wrong just for how it's phrased: it's meant to manipulate based on fear of being left out. I hate being manipulated.
Beyond semantics, however, this can be achieved by KDE simply setting schedules and sticking to them, as we did throughout KDE2 and KDE3 and have begun doing again now that KDE4 is on the tracks. It has nothing to do with set schedules or synchronization.
"Getting the release out is the most important feature."
Absolutely.
"It would be wrong for KDE to specifically pick a distribution to sync with. Instead pick a date which 'conveniently' matches that of other software at the same level in the stack"
This is a classic tactic: recognize the flaw in your position, then spin it slightly differently. Honestly, I don't care if we were sync'd with someone. I care that our development processes work well. Synchronicity matters not one bit if the product is hobbled.
"Regular time-based releases are much easier if features can be landed when they are complete, so that the primary work going on in trunk is integration [..] The kernel developers have proved that this approach can work."
Absolutely; but again this doesn't address the issue of the size of the time based schedule. The kernel developers do not use a six month cycle.
"The regular cycle may have to be suspended for big backwards-compatibility breaking upgrades (KDE 4)"
Absolutely.
"The value of synchronization is sufficiently high"
What is the value, exactly? I mean to the software development process that actually creates the value in the software in the first place. I get downstream's benefit, but since this "value" to them comes at a cost to me and their value is a derivative of my value ... can't they see the shortsighted nature of this position? Really, show me the value. I've challenged people who take this position to do it many times in the past and it turns out the value is in integration and immediate gratification for users. Excuse me for being a strategist, but I'd prefer to win in the long term.
So show me the value. Show me the actual measured benefits of a six month cycle that is generally applicable to every software project.
"The time delay is subject to debate."
Great, because that's pretty much what I'm debating. We either need a way to allow for multiplicity in time delay for development while keeping synchronicity in delay for release, or we need to adjust the delay. But seriously, when Mark says this and then follows it up with "oh, but 6 months is what we found best because ..." and then continues to go on at every opportunity how people should be on a 6 month cycle, the agenda is pretty clear. It may be up for debate ... as long as that debate is whether it should be 6 months starting in April or 6 months starting in October.
So, to reiterate: I'm not against time based development, I'm just not in favour of binding development time frames to the artifice of 6 month release cycles that have exactly one benefactor (distros) and many who pay (upstream and eventually the users).
12 comments:
From a developer view you are certainly right. Who cares about a not good product only because it is synchronized with other products?
However I believe that distros has to be keep into more consideration.
See Gnome success thanks to Ubuntu.
At the moment, Kde4 is technically superior to many competitors but history shows us that is not enough for diffusion...
I think Mark is suggesting you something. Obviously he can't say: " Hey guy we provide ubuntu with Gnome cause it has more stability according to companies why don't you do something for this?"
A good product worths nothing without large diffusion that can start bandwagon effect
> What you really want is a staggered approach where B releases right about when A starts to work on things.
Well, I can't speak for other distributions or even for Fedora as a whole, but in my experience as a Fedora packager what we actually want is an approach where upstream releases right before downstream stops to work on things, in other words: the optimum point of release for an upstream project is a few days before our final development freeze. We will start importing alphas and betas into Rawhide very soon in our release schedule, then track them until the official release. It's OK if the software is still in beta when our feature freeze hits (especially if it's itself feature-frozen, but that's not an absolute requirement, Fedora Release Engineering is relatively flexible with feature freezes, their main concern is to avoid breaking things, not to enforce a hard feature freeze), we can (and normally will) still import bugfix updates (which obviously includes beta->final updates) during our feature freeze.
"I believe that distros has to be keep into more consideration."
in terms of release timing, which distro? they don't release at the same time, let alone at the same frequency.
i'd also suggest that timing a release helps the distro by giving them a feature checklist every N months ("new version of FOO!"), but that's pretty empty if it ends up hurting the actual quality of the product. trading long term success for short term partnerships is not wise; well, unless you only care about today.
i want to see more roll outs like the Brazillian school system or the EEE PC stuff. that's a level of success that Ubuntu can only dream of at this point; they have done well in the present with the enthusiast community, but that's neither guaranteed to last nor has that translated into even a fraction of KDE's real world deployment numbers.
but really this is a moot conversation because we can do releases every N months for virtually any value of N, as long as we don't pin down the development process to it. release and development perhaps need to be decoupled.
my point in this blog entry is not "let's forget about distros", but rather it's "let's not buy into arguments that don't have merit, regardless of where they come from"
making decisions based on poorly constructed initial assumptions is a recipe for disaster.
"Hey guy we provide ubuntu with Gnome cause it has more stability according to companies why don't you do something for this?"
i don't think there's much truth in this statement. it's not why Ubuntu comes with GNOME, it's not the perception of KDE v GNOME in the market as reflected by actual usage.
@kevin: "the optimum point of release for an upstream project is a few days before our final development freeze."
absolutely; unfortunately the operating system vendors (OSV) don't share a cycle themselves! so setting our cycle to any one (or, if you're lucky, two) OSV's cycle doesn't do much for solving the general challenge.
of course, i'm sure every OSV would like the world to pick them to sync with. =) but back in realityland:
if it meant a real world increase in investment in development, marketing or some other useful asset to upstream we'd have a much more interesting conversation. unfortunately, the arguments given as to why it's good for KDE as an upstream are pretty hollow at the moment, and there is no quid pro quo being offered.
BUT, as i said in my blog, i think we can satisfy both up and down stream needs here. finding a way to do that implies understanding the landscape of the problem accurately, though, and i don't find Mark's argumentation a help in that respect.
so.. going back to the "but which distro to sync with?" problem: wouldn't it be really neat to practice a development methodology upstream that would allow releases to be rolled "on demand" for downstream.
that way every downstream could have a release just when they wanted it with the margin of error being the smallest unit of release branch sync.
this is a bit utopian and i don't think we'd ever get 100% there, but with a system of rolling, incremental development i think we could get pretty close to this.
projects could then maintain their own development rhythms while giving access to a stable stream for downstream to sample from. it has nothing to do with 6 month cycles in my mind, and is certainly all about having flexible release capabilities not constrained development cycles.
My (sort fo) random idea on this topic is that Linus Thorvalds get it right. If I've understood kernel development correctly their timebased release is based on a general idea. Linus have his idea of "ideal time" where he sais how it should be in a perfect world. But he let this timeframe slip for the sake of quality.
I do see this as the best timframe to use. One set up what would be ideal and tries to stick to this on a best effort basis. But still let the timeframe slip to achieve the quality one demands. The gain one win here is a bit pressure on developers to do things in time, and also pressure to deliver quality. Pluss a general idea for users when they can expect next quality relaese from their favourite desktop environment ;)
So I would not tie any release schedule to any one, but just pick the best schedule for the project.
It would be nice if things could sync up and all projects could have nice little staggered release schedules so that packagers had time to put everything together. However, I completely agree with you Aaron, it seems like it's largely a pipe dream and that the system could easily fall apart simply when one project had a schedule slip (which is inevitable in software development). I think that this situation would be alleviated if distro packagers were a little more aggressive about getting updates into repositories and out the door. As it is right now it is largely a waterfall model of distro releases (large releases every 6 - 8 months), but I think that moving to a more iterative approach (smaller updates that are more staggered) would be beneficial. As it is right now, upgrading from one distro release to the next is often quite difficult (and there is a pretty good chance that it will break things), I think that replacing one major software component at a time instead of doing 20 at once would make for less headaches and would give users software that is more up to date.
I'm upset with Mark over a couple of things related to Kubuntu, but I don't think an idea should be disregarded out of hand because it comes from Mark. This whole angle of "This could benefit Canonical? Screw 'em!" is getting out of hand. Especially since it's been said that Ubuntu will change its own schedule if that's better for everyone else.
I think this idea ultimately rests on distros choosing to synchronize. If Fedora, Suse & Ubuntu released on the same day (or week or month) then there would be considerable pressure on upstreams to have something notable finished in time.
The point about marketing comes in here. If the FOSS desktop market continues to grow, then the ratio of advanced to average users will continue to fall towards average users being dominant. New versions of KDE, Gnome, XFCE etc. do not get included in the standard update pipe of the popular 'user-friendly' distros.
The upshot? For the average user, a new release of X-DE means nothing until the new version of their chosen distro is released. And when openSUSE 12.2 comes out (for example) can their press release hype the new version of XDE that's included? The question for each project then becomes "do you care if users are getting a release that is 1, 2, 3, 4+ months old?". Obviously, some projects will be more concerned with that than others. So the answer there is up to the developers.
About up/down/across stream coordination:
Maybe I haven't read/heard enough of Mark's comments but I'm pretty sure he's not suggesting a situation where A & B should be released at the same time if A depends on B. Who honestly wants the compiler, cmake, KDE & the distros to release on the same day? That helps no one.
Obviously dependencies should be staggered in their release. But the question is, will the staggered release be deliberate or happenstance? A properly functioning internal combustion engine is in sync, but that doesn't mean every piston fires simultaneously!
What has been suggested is that some things would be easier if distros had a synchronized release. If even a pocket of the active distros decided they were going to agree on a common kernel release, they could pool their kernel-focused resources rather than have each kernel team dedicated to customizing some a.b.cc-dd release on their own.
Why wouldn't the same collaboration style apply to other pieces in the stack?
It becomes a self-fulfilling prophecy to say 'we shouldn't test this out because there's no evidence' - when no testing has been done to collect evidence.
@Refilwe Siphiwe: "I don't think an idea should be disregarded out of hand because it comes from Mark"
me neither. but a bad idea is a bad idea is a bad idea, and Mark's ofered justifications for his idea are, imho, not compelling and mostly just plain wrong.
so it has nothing to do with where it came from, just the validity of the concept in general.
'The question for each project then becomes "do you care if users are getting a release that is 1, 2, 3, 4+ months old?"'
given that the release would have been the most recent one at the time of the distro going out the door, and that these users would only pick up the new release on distro version upgrade as you noted, isn't this an irrelevant question?
it's new for the user.
"I'm pretty sure he's not suggesting a situation where A & B should be released at the same time if A depends on B."
Mark hasn't been overly clear on this (it's all a bit handy-wavey at times), but the position he states is that all major projects should release at the same time.
the case of KDE relying on Samba is a concrete example here: if they are released at the same time, KDE probably won't be able to use new features in Samba until another rev cycle. that pushes that feature out another 6 months.
due to there being a complex maze of reliances between software packages, we'll probably end up with feedback cycles of various forms. those postponements will keep adding up and the feature rate will fall further and further behind.
assuming we could even orchestrate such a level of simultaneity, something i highly doubt.
"Obviously dependencies should be staggered in their release."
staggered how and where? there aren't precise layers in the software stack, and there are indeed so many of those layers, even if we chunk them very grossly (build chain, kernel, userland infrastructure, servers (x.org, samba, etc), desktop) and try and stagger them out through the 6 month cycle what do you get?
yep, no synchronization with the distros (a major point of this exercise, right?), no real media "bang" and not really enough months to make it all work.
if you need a 2-3 month stagger minimum (and i think even that is cutting it thin) it implies there's only room for two layers per cycle. that means that build chain and kernel will have to be a year or three ahead of the leaf nodes (depending on exact chunking) and lord help us all if there is some sort of cyclical support/feedback system between components in different chunks.
"they could pool their kernel-focused resources"
yes, this probably all makes a lot more sense for distributions.
"Why wouldn't the same collaboration style apply to other pieces in the stack?"
because Fedora doesn't depend on Ubuntu; because packaging and integrating released software is an entirely different ballgame to creating said software in the first place (one is making pieces that exist fit together, the other is figuring out how to design and build those pieces; a bit of a simplification, but generally accurate)
"a self-fulfilling prophecy to say 'we shouldn't test this out because there's no evidence'"
i've never crashed my car into a wall at 100kph to find out if it hurts, either.
some things are indeed debatable or need experimentation.
other things are just so obviously a bad idea that it can be deduced through analysis alone.
(yes, the latter takes a measure of expertise, intelligence and thought .. )
“a bad idea is a bad idea is a bad idea...it has nothing to do with where it came from, just the validity of the concept in general.”
We know it works for Gnome. We know it works for *buntu. Mandriva is back on it. Fedora has moved towards it as well. OpenOffice is looking at 6 month releases. Even KDE is now on a 6 month cycle. If it's even “mostly” wrong where was the huge opposition and debate then? Only now that the discussion is moving towards “6 months at the same time” *now* people have major issues? And *now* it's not a valid concept?
'The question for each project then becomes "do you care if users are getting a release that is 1, 2, 3, 4+ months old?"' given that the release would have been the most recent one at the time of the distro going out the door, and that these users would only pick up the new release on distro version upgrade as you noted, isn't this an irrelevant question? it's new for the user.”
But if developers depend on users for broad feedback then how far behind the users are matters. If users were all getting KDE 4.0.0 now in the new releases of openSUSE, Kubuntu and Fedora...that has an impact on KDE. So it is not irrelevant, unless developers would rather receive the bulk of their feedback on older code. For some projects that may be less of a concern than others.
And I release that a ton of FOSS code is of the “I love to code, I'm scratching my itch, you can take it or leave it” sort. But if users don't factor to any notable degree in our planning (especially in “primarily for end-user” dominant projects like the D.E.s , office suites, browsers, etc.), what are we aiming towards exactly? Pervasive free software among...non-users? Users are the distros' (and everyone else's eventual) "downstream". Streamlining the process for distros helps users get the latest editions of everyone else's stuff.
"the position he states is that all major projects should release at the same time...KDE relying on Samba is a concrete example here: if they are released at the same time, KDE probably won't be able to use new features in Samba until another rev cycle. that pushes that feature out another 6 months. due to there being a complex maze of reliances...the feature rate will fall further and further behind.”
You're right that Samba releasing at the same time as KDE would prevent KDE from using the latest feature. For KDE to use the latest Samba, Samba must release before KDE. Makes sense. So it's good for KDE's dependencies to release before KDE to help KDE get the latest stuff included, but it's bad for KDE to release before the distros so the distros can get the latest stuff (assuming the distros were synchronized)?
In any event, the whole point of time-based releases is the acknowlegement that not everything will make it this time. It's not terrible however, because we all know exactly when 'next time' will be.
With our current scheduling 'model' projects have to delay certain features/implementations because of their dependencies anyway. So the suggested shift isn't creating a new problem.
"'Obviously dependencies should be staggered in their release."
staggered how and where? there aren't precise layers in the software stack...
if you need a 2-3 month stagger minimum (and i think even that is cutting it thin) it implies there's only room for two layers per cycle. "
Well “6 months” isn't hard and fast. Could be 8 months, 9 months. Plus, many of the layers don't need to be synchronized for the appropriate effect of this idea, pressure will move upstream naturally. If Fedora, Mandriva, Suse, *buntu are all releasing on say an 8 month Jan/Aug/April cycle. Pressure will move towards major user-focused software (D.E.s, office suites) to release in time for those dates.
The developers of major user-focused software have always had to use the best available of their dependencies (build chain, servers etc.) so nothing has to change on that front - KDE already as to wait for Trolltech, the Samba devs etc. to develop certain things before they can advance particular concepts. I don't understand how if KDE syncs with other major user-focused software, the very same “we need your feature X to do our feature Y, so if you're late...we gotta wait” that's already going on (and has been going on) in the current model suddenly becomes a big issue.
At the end of the day, this is about distros coming together. Under the model of major distro releases all over the calendar, it makes sense for everyone else to say “we release, when we release, so pick a version and run with it” - people don't want to look like they are picking sides. But if all major distros are releasing in the same month, every time...what sense does it make for OpenOffice or a D.E. to release 5, 10, 15 weeks after their hard freeze date?
I'm sure this idea will have it's pain points. But I do not consider it an obviously bad idea that isn't worth trying. Then again people are destined to disagree on something.
@Refilwe Siphiwe: "We know it works for Gnome."
that is highly debatable. i read a university thesis paper on this exact case and the researcher came to the conclusion that the 6 month release cycle had caused a distinct and measurable drop in innovation and involvement.
you may or may not have noticed, but the last couple years of releases have been less than staggering.
it has gotten GNOME other things from the release side, but from the development side it really doesn't seem to be a winner.
there's also some interesting correlations between mailing list traffic and their move to a six month cycle.
"We know it works for *buntu. Mandriva is back on it. Fedora has moved towards it as well."
those are distributions. i'm not sure what part of "integration is a different process than development" is so hard to understand?
"OpenOffice is looking at 6 month releases"
so is Samba. and who knows, it might work for them. as i've said a few times now, it's not a one-size-fits-all. that implies that it will fit certain projects.
the idea, however, that all design and development processes are equal is really not true. so we have a "make it all the same" for a situation where all the things simply aren't the same.
the answer i'm proposing (if you go through the full blog meme on this topic) is to detach development cycles from release cycles, and instead concentrate of making it possible create releases from point in time samplings of the development process.
"And *now* it's not a valid concept"
well, no. i've never thought it to be a valid concept. i've spoken out about it within the kde community for a while. i just haven't blogged about it =)
if you're wondering why i then presented about the 6 month cycle in my keynote presentation in january ... you have to realize that when i put on my "project ambassador" hat and serve as a spokesman for the project, my own personal agenda must take a back seat to that which the project as a whole is moving in. i represent KDE at such times, not myself as a lone actor.
here on my blog and on the mailing lists, however .. i represent myself as one person within the project.
"if developers depend on users for broad feedback then how far behind the users are matter"
sure; we do have a good contingent of people who do track us at every stage. i routinely get defect reports against svn trunk (which is great). having a 6 month lag (worst case scenario, right?) is really not a big deal.
then again, with the release!=devel system, this is a moot point entirely.
"But if users don't factor to any notable degree in our planning"
so having a non-six month cycles equates to not factoring in our user's needs? pleeeease.
step back from your rhetoric for a moment and consider that the reason i'm against such a development cycle is that it results in software that is not as good.
it makes it harder for developers such as myself, and that's really the last thing user's need as well (a higher bar for others to participate and create on their behalf)
"Users are the distros'"
that doesn't mean that the distros should then be obeyed mindlessly to our own detriment.
pandering endlessly to your audience without care for what your expertise says will serve the audience well is not caring for you users.
in this case some people are asking for something that they evidently don't understand is patently unhealthy for the ecosystem.
"So it's good for KDE's dependencies to release before KDE to help KDE get the latest stuff included, but it's bad for KDE to release before the distros so the distros can get the latest stuff"
logical fallacy, since one is not like the other.
KDE can't create features on software we don't have. distributions merely can't ship software they don't have. the software still exists.
now, if we impair the ability for the software to be developed, we also screw over the distros because they won't have those features to ship.
moreover, the real problem is the domino effect on software projects: if samba doesn't release in a timely fashion, then kde can't use it in our development and that software never gets written; in turn anyone who would rely on that set of features in kde can't move forward either ... continue until the dependency chain ends.
if a distro doesn't get a kde or samba release within the right couple of weeks, the only impact is that release of that distro. period.
that's why they are called "downstream".
it's a little more complex for groups such as the suse or mandriva teams who actually participate in upstream development in meaningful ways, but it's not significantly different.
"whole point of time-based releases"
i'm not against time-based releases.
"that not everything will make it this time."
that's true of pretty much any release cycle strategy. the question is how much can make it, what is the quality of the results, etc. a 6 month cycle not only is a poor fit it, as i've covered already, encourages bad habits such as feature dumping on the eve of freezes.
"we all know exactly when 'next time' will be."
knowing when isn't interesting. having the features actually make it in in a reasonable time frame with reasonable quality supporting processes is.
you are completely missing the point here.
"So the suggested shift isn't creating a new problem."
once again, i'm not against time based releases. i'm against a fixed 6 month cycle for them.
"Could be 8 months, 9 months."
see, we agree.
"Pressure will move towards major user-focused software (D.E.s, office suites) to release in time for those dates"
pressure alone does not make something better. it just makes it easier to succumb to.
i know that suggesting that one applies critical thought to the systems of creation is a little radical for the free software community ... but let's try and be a bit progressive.
"I don't understand how if KDE syncs with"
i've already explained this in detail on my blog entires on this meme. if you don't understand it, you may want to read what i've written again.
"this is about distros coming together"
which is pretty much irrelevant for upstream development processes. the distros are not positioned nor incentivated properly to ensure the health and well being of upstream. at best they are a delivery mechanism, and we should try and help them out with that delivery.
but impacting the development cycle to blindly conform to a group of people who have a different set of priorities and are, to be perfectly frank, far less focussed, consistent and requiring in creativity than the upstream software projects themselves is really not the best of ideas.
"what sense does it make for OpenOffice or a D.E. to release 5, 10, 15 weeks after their hard freeze date"
it makes sense if it means that OpenOffice actually moves forward with a healthy development process.
i'd rather see it release after a distro release if it means OpenOffice improves faster or even just more consistently. there's always the next distro release, after all.
you seem to be taking for granted that the health of upstream projects will not be affected by this. that's an assumption that is not only not a given, it's one for which there are a number of non-trivial reasons to outright doubt.
"But I do not consider it an obviously bad idea that isn't worth trying."
if we're honest, i think it already has been tried. release management is not a new science. not even in the free software world.
"Then again people are destined to disagree on something."
yep. comes with freedom =)
I know you dislike the idea of 6 months releases (forget the period, it can be a year, or wathever, just think aboudt synced releases), but from a user perspective, it is very good.
Actually I do not belive he is talking about projects like KDE, but more likely distros.
Think for a moment, if all distros ship with the same KDE release (let's say 3.5.6), most bug reports will be for this version, most bug fixes will be for this version, most patches will be for this version, and all distros would have to apply the patches.. to the same version.
I can see the benefits here.
BUT (big-but) I do not think it should matter for projects release cycles, just for what release from projects the distros would pick - it should be the same.
So do not crucify the idea just because it is not good for you, we can find a common ground here ;)
There are benefits in the 6-month schedule, please do not keep bashing over-and-over (3 posts in sequence) it :-P
@Aaron,
Just out of curiosity...at what university was that thesis paper you mentioned published? I would really like to read it.
And I would go even further than you do...I'm against set time based releases whether it's KDE, Oo.org, or distro X if only because it increases the likelihood that something will be rushed to meat the deadline. Which is why I REALLY like the idea of the "it's always summer in trunk" and I hope something can come out of it.
Post a Comment