[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: RFC: The Road Ahead
From:       Lauri Watts <lauri () kde ! org>
Date:       2001-07-25 17:57:48
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]