Toward time-boxed development for KDE

[Sebastian Kuegler]

On Wednesday 09 January 2008 00:09:30 Kevin Ottens wrote:
> --------- Executive summary
>
> In this mail I'll be advocating the way I think we should make our release
> planning from now on. Some parts will look similar to what we were doing,
> some won't. I think doing strict time-based release would be a mistake and
> I think we should do ourselves a favor by having something more flexible.

Executive summary of my reaction:

KDE is too big to make its schedule dependent on single features. A time-based 
schedule is preferable because it gives our partners (upstream and 
downstream) a solid idea of when the new KDE is there. Commitment to 
plannable release dates is very important.

I like your proposal of how a release cycle should look like. This doesn't 
seem to depend on time-boxed, though.


> Now I also think we have a couple of things to fix:
>  - Communicating to the outside when our release is getting ready. I'm not
> talking about marketing here, but release management of related projects
> (like amarok for instance) or downstream like distros. That said marketing
> would surely benefit from it too.

There's a lot to be improved, yes. If we only had proper changelogs for point 
and point-point releases, that would be a lot of help already ...

> --------- Proposal: time-boxed development
[...]
> So in short, the benefits I see in such a scheme:
>  - we're more predictible

We're less predictable than with a commitment to a fixed date. That is a 
pretty central point for me. Commitment.

>  - we keep flexibility for KDE5 without having to push for a completely
> different cycle (it's basically just a longer feature list, in particular
> for kdelibs, and having an earlier freeze for kdelibs)

Wait, let's not mix the next major in here. We should bring it down to the 
less complex 'release plan for point releases. Trying to find some general 
release strategy which fits feature updates (4.x) major version (5.0) is not 
necessary for the next years, so let's cut down complexity here.

>  - we share the load of the release management

I don't see how / why. Can you explain?

>  - we get toward a release based on the current status of the codebase and
> feature lists, not some external factors

I think the problem is that our codebase is too complex. As Simon said, 
there's always the bigger thing, and there's always something that might or 
might not make it by two weeks. IMO we're just too big (or big enough) to 
move away from focusing on single features.

>  - we're better at communicating what we're doing, and the status of the
> codebase

Again, I think that's much easier to do if we have a predictable, time-based 
schedule. It's just easier to understand if you can pick a calendar and 
see "ah, warmup phase right now". It also makes communication to our 
developers much easier.

> --------- Why I don't buy "time-based release"
>
> Mainly for two reasons.
>
> First as pointed out at several place (and in particular in Martin
> Michlmayr PhD), there's real concerns regarding innovation with such
> release planning. That means that you would have to use a radically
> different cycle for major versions, that's somehow what we did to get KDE
> 4.0 and we probably don't want that anymore. People are change resistant,
> you break habits when you change the type of release cycle. And we don't
> want to prevent innovation, do we?

I don't agree with the don't anymore. As I said earlier, it makes sense to 
exclude major cycles from this planning. In this light, Michlmayr seems to 
propose exactly those time-based cycles. I also don't think innovation is a 
problem, rationale is the 'meta-project / too big' argument above.


> Ok, now it's late and I'm tired, just hoping I didn't write too much
> bullshit in there.

Hardly any. :-)

> Comments are of course welcome. :-)
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20080113/e0160055/attachment.pgp