On Wednesday 25 July 2001 09:16, Simon Hausmann wrote: > On Mon, Jul 23, 2001 at 02:07:01PM -0700, Waldo Bastian wrote: > > To wrap up the Qt3 discussion and to bring everyones expectations a bit > > in line, here is a proposed time-table for the rest of this year: > > > > Aug 2001: Release of KDE 2.2 > > Sep 2001: Release of KDE 2.2.1 > > Okt 2001: Development release, KDE 2.89 aka Qrash3. > > Nov 2001: KDE 3.0beta1 > > Dec 2001: KDE 3.0beta2 > > Jan 2002: KDE 3.0 final > > > > I suggest to switch KDE CVS to Qt3 after the release of 2.2.1. I would like to suggest a rather radical change to the whole KDE development cycle for consideration/evaluation. Based loosely on the FreeBSD and Debian models, I propose that CVS is branched to a -STABLE branch, leaving -HEAD as unstable. Periodically when -STABLE really is stable, announce a release date a few weeks in advance, freeze the feature set and strings, as we do now, and snapshot this branch for release. I realise that in the past we have not had developers testing and working on the branches, but I believe this can change. In the past there has been no great incentive to work on the branches, with a changed structure, this would be where most development really goes on. It would need to be made very clear that -CURRENT is for bleeding edge, new features, and testing of new code, and that as soon as it's stable it is merged back to the -STABLE tree, where any further bugfixing and perhaps smaller enhancements are made. I think this would give several advantages over the current system, in particular: * Developers never have to sit on patches for extended periods of time, the -CURRENT branch is always open for commits and new features. I've watched the frustration with this situation grow on the lists and on IRC, and I think it could easily be a problem if there is a more-or-less feature freeze for another whole 6 months. * Developers never have to jump through hoops to make bugfixes that don't upset translations, because * The feature freezes will be much easier on both sides, developers won't be stifled by them, and there is more chance they will be respected, giving docs and i18n a much more stable platform to be working in. * Translators and Documentors, many of who are new and/or inexperienced, don't have to run a bleeding edge codebase in order to contribute, because code isn't merged back to -STABLE until it is reasonably stable. There's a better explanation of how it works than I've given above, on this page: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html Debian uses a very similar development cycle, although in three stages, rather than two. I do understand this would be a radical change, and it might take a while to work in practise. Given the userbase of people who already run CVS HEAD code, it might even be more practical to reverse the branching, so that HEAD is the stable branch, and new development is done in a new -UNSTABLE branch. There are disadvantages also - the need for quite some developers to be working on both branches at once. Based on what I've seen on the lists, many of the core developers already are doing this, running the previous release for day to day work, and installing CVS HEAD under a different user or on a different machine, so I don't think that argument is too difficult to overcome. I guess you guys will be able to suggest more disadvantages, and I expect you soon will :) So, asbestos suit is on, evaluate away. -- Lauri Watts KDE Documentation Coordinator