Toward time-boxed development for KDE

[Kevin Ottens]

Le dimanche 13 janvier 2008, Sebastian Kuegler a écrit :
> 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.

That's fine if you allow yourself to push back easily. Of course I'm not 
advocating to decide on all the features in advance and not release until all 
the features are in. The idea is to put frequent check point when you 
reevaluate what will get in or not. Once this regularly updated list is empty 
you start stabilizing.

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

The time boxes are on the inner cycle of development (the snapshots), in my 
example it was one month time boxes. I should have made that clearer.

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

Sure, but if you commit to a fixed date you can't commit to actually making 
progress in the same period. That leads to anemic releases IMO.
(Note that I'm not saying you can't make progress, you just can't be sure 
their will be... in particular in a mainly volunteer project)

Now that's why I proposed the time boxing, you're still more predictible than 
if you're purely feature driven (and release once everything is in) and you 
give yourself the opportunity to foresee the right release date enough in 
advance to communicate it.

Of course it's less predictible than saying we'll release every X months 
whatever happens... which has a price.

Hence why my proposal was more about a compromise.

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

Sorry, but IMO we've to keep it in mind nonetheless. Changing completely the 
way we work for major releases just leads us to loosing more time. We had a 
period where the release management was in a state of flux, habits had to be 
changed, and now they'll be changed back again. It definitely has a price 
too, so coming up with something that can manage both cases with minor 
changes is an advantage IMO and must be evaluated as such.

> >  - we share the load of the release management
>
> I don't see how / why. Can you explain?

The way I structured the proposal I gave more importance to the release 
coordinators on purpose. They'd get a much more proactive role in driving the 
release, while for now apart from cleaning up which application is in a 
module they don't seem to be very active. In the end the decisions are taken 
randomly or with a 10000 feet high view on the module.

I might be wrong here of course, but I don't recall much activity from module 
maintainers for our last release. Note that I'm not blaming anyone, it's 
currently hard to really know what you'd be supposed to do as a coordinator 
hence why I tried to make that more explicit.

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

Not sure I understood what you meant here.

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

Again I think it's about a compromise between what's good for the project 
itself and the ecosystem around the project. As for communication to our 
developers the time boxing is IMO more efficient, because you poke them more 
frequently and regularly (not only every X months).

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

Not sure I understood that. You want to prevent innovation? I don't think so, 
I probably misunderstood you. :-)

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

Actually, the point of Michlmayr in favor of time based cycles is the quality 
of the output. But, the innovation is still a raised concern with such a 
cycle... While the quality of the output can be ensured by other means, 
frequent snapshots which have to meet a set of criteria being one of them.

> I also don't think innovation is a 
> problem, rationale is the 'meta-project / too big' argument above.

I don't see why being "too big" suddenly allows us to innovate more easily in 
such a release cycle while others obviously are known to have issue with 
that.

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

Ah pfew! Seeing the tremendous amount of interest for this thread I was indeed 
wondering. :-)

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20080117/c6b8094a/attachment.pgp