Change release schedule 4.2 and schedule for 4.3

[Aaron J. Seigo]

On Tuesday 09 September 2008, Cornelius Schumacher wrote:
> always had a shortage of people working on stable branches.

that's a really, really good observation, imho.

right now it seems most of the people who write code for KDE but use one of 
the stable branch(es) are application developers. it seems the further from 
the "core" their app is, the more likely they are to us a stable branch.

personally, i've had far more interaction with coders-using-stable-branch 
since extragear happened, mostly because it brought an audience that uses the 
stable branch closer to where i live. that's been one of the big plusses of 
extragear for me personally.

then we have non-coders who follow svn. many of those that compile their own 
KDE do so from the stable branch and have historically been an Ok (though not 
perfect) source of feedback for the stable branch.

all the same, your observation that we don't have enough people working on 
stable branches is spot on in my opinion.

some thoughts that float into my mind while thinking about it are (warning: 
brainstorming / mindwandering ahead):

* we could just accept this as part of our reality and try to make the branch 
most coders use day-to-day (trunk) become where most of the stabilization 
activity happens

* try and find some way to encourage more people to use the stable branch(es)

	* that means identifying _who_ we should encourage in this way: perhaps 
application developers .. should people working on apps in kdegraphics (to 
pick one out of the air) who do not work on code in kdelibs or kdebase use 
ibs/base from the stable branch? (right now that would be 4.1) that could be 
hard to convince people of right now, but as libs/base continue to mature 
nicely, perhaps it's realistic to get 4.3 app developers to develop against 
4.2 branch libs/base?

	* that would limit the number of people using kdelibs/kdebase from trunk, 
though!

	* so we'd need the stable-branchers to switch ASAP to the soon-to-be-stable 
branch; e.g. if we branch from trunk 3 months before release to start 
stabalizing 4.3 

	* this might make it harder to get people who write applications to start 
contributing to libs/base? or maybe it would be just as hard as ever.. ;)

	* this might make it a little bit harder for people working on libs/base to 
contribute to the other apps as they would be using trunk while apps would be 
using the stable branch ... but perhaps libs/base devs just wouldn't using 
very many "cutting edge" bits of API in that case? (that's what happened when 
i worked on ktorrent's plasma stuff last week, actually; and it wasn't bad at 
all)

sooooo .... it could look like this:

4.x development starts (marked by the branching of 4.(x-1))
	* libs/base developers are on trunk/
	* application developers would be encouraged to use trunk/ only for 
applications, but stick with the stable branch for libs/base to increase 
testing

4.x feature freeze
	* libs/base developer stay on trunk
	* application developers are encouraged to move to trunk libs/base

4.x beta releases start
	* 4.x is branched off of trunk
	* libs/base developers stay on trunk, backport fixes as they go
	* applications developers move to 4.x branch

i wonder if we could get enough app developers to do this? to work it would 
require:

* cheap branching/merging/switching branches (svn fails here, git would work 
well)

* clear communication at each step (e.g. "if you are in group $FOO, run this 
command in your source tree now: $BAR")

the downside to this is that applications would mostly use features only from 
the last release of libs/base. bug fixes to libs/base would have to be 
backported to the stable branch more agressively for wider testing. we'd lose 
some of the immediate synchronicity between libs and apps in the process.

of course, some apps could decide to follow trunk libs/base either perpetually 
or for just specific releases that require cutting edge features.

everything would still be released together, of course, so the work done by 
everyone on libs, base and apps during the 4.x cycle would end up as 4.x

i hope that i'm not overthinking this .. =/

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080909/f2d7553d/attachment.sig>