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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
