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).