Change release schedule 4.2 and schedule for 4.3

[Aaron J. Seigo]

On Monday 08 September 2008, Cornelius Schumacher wrote:
> On Monday 08 September 2008 20:08:50 Aaron J. Seigo wrote:
> > i'm increasingly viewing development-tied-to-resleaes as a stupid idea
> > but it's the reality we deal with for 4.2 and probably 4.3.
>
> I hope that people don't forget that developing without releasing is just
> nothing, not even stupid. The whole point of developing KDE code is to get
> it released at some point in time (and preferably often and early as it has
> proven to be essential in the open source development process).

the alternative to "development-cycle-follows-release-cycle" is not 
necessarily "don't-release" (though that is one possibility; one that is, as 
you note, worse than stupid). 

the idea that was floated is, essentially, to allow release engineering to 
happen alongside development without forcing one schedule to mimic the other 
100%. 

right now we have situations like the PIMsters lining a meeting that works 
well with the 4.2 schedule. but then the 4.2 schedule shifts through no fault 
of their own and they are no longer *allowed* to work on features when the 
meeting is scheduled. crazy.

so either the 4.2 release schedule fits PIMsters, or the PIMsters work in 
branches, ignore the release schedule and just merge into trunk when it makes 
sense.

the latter is what is being suggested.

for the Plasma team, it would remove the cause of the "two clump" phenomenon 
where we have two major drops of features each cycle: once at the start of a 
dev cycle, and again right before feature freeze. the result is a lot of 
stabilization efforts in between that shouldn't be necessary. if we are allowed 
to work in trunk/ as a semi-frozen branch with more active work in one or more 
"hot" branches sync'd over every 1-3 weeks without break, things would be a 
lot smoother.

stabalizing for a release would be no different than what we do now, which is 
fix things in the devel branch and backport those fixes from trunk. today 
there's a disincentive to do so because of the mad rush to meet the feature 
window and because svn makes branching and merging harder than it needs to be 
(at least historically; yet to see if 1.5 actually makes my life easier).

we also have a larger number of people running the stable branch for day-to-
day development, so we shouldn't have the 4.0 problem of "nobody actually 
using backported commits"

bottom line: if we do disentangle release-from-development-cycles, release 
timing and quality need to at least match what we're doing now as a bare 
minimum.

> Summer feelings are nice, but we are working on software used by millions of 
> users who are looking forward to bug fixes and new features after all, not on 
> the KDE version of Duke Nukem Forever.

indeed. thankfully that's not the proposal that was made.

-- 
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/20080908/c76d9562/attachment.sig>