Change release schedule 4.2 and schedule for 4.3

[Aaron J. Seigo]

On Tuesday 09 September 2008, Boudewijn Rempt wrote:
> On Tue, 9 Sep 2008, Torsten Rahn wrote:
> > On Tuesday 09 September 2008 14:32:19 Cornelius Schumacher wrote:
> > > On Tuesday 09 September 2008 12:39:07 Sebastian Kügler wrote:
> > > > We have become too diverse for the current, rather limited
> > > > development model and tools.
> > >
> > > I don't think this is an accurate statement. Our development model is
> > > well developed and has scaled tremendously well. Alone the fact that we
> > > are still able to do releases of our millions of lines of code shows
> > > that. With extragear and all the third-party apps which are maintained
> > > outside of KDE we have a model which allows for a huge amount of
> > > diversity.
> >
> > I very much share Cornelius' concerns.
>
> Me, too, as I already wrote in a reply to the dot story that was a preview
> for this discussion. I think that not only a lot of cohesion will be lost

where will the cohesion be lost? or rather, what do you attribute the current 
cohesion to? some seem to think it's mostly social and coordination based, 
others think its mostly rule based, others think its technical constraints 
.... i'm interested in understanding more about the different value people put 
on the different aspects of the model we currently have.

> and that people will be spending a lot of time merging instead of coding,

maybe i'm just strange (ok, we already know i am ;), but i already spend time 
merging code from branches (playground is a big one for us) and patches 
(bugs.kde.org, random people popping up on the list with a patch, etc). this 
is not a bad thing, it's part of a process that increases the reliability of 
the code base. not everyone needs to be coding constantly; there are both 
social and technical benefits to having some people who code but also spend 
some time merging too.

> we'll see a return to the merge-at-the-last
> moment, where integration of all new code is postponed to when the release
> is supposed to be made.

return to? that's what i see happen now. merge-at-the-last-moment is actually 
the *opposite* effect "always Summer" should have. it's actually the reverse 
problem (never merge, always fork) that's the bigger risk.

(always interesting how different people have such different personal 
interpretation of a shared experience, isn't it? =)

what this does tell me is that if we adopted the "always Summer" approach that 
those who are leading the transition would need to provide some rather clear 
notes on:

* how to keep developing like you always have if you don't need change (aka 
"it works perfect for me already")

* how to take advantage of benefits without screwing yourself in the process 
(e.g. never releasing, last minute merging, etc)

* how NOT to take advantage of the system

note that this is no different than what we have now; people just understand 
what we have now pretty well.

this is probably responsible for a large amount of the benefit that Cornelius 
talks about with our current system that's evolved over time, and can be a 
disruptive cost if we switch and don't provide effective documentation. 
"effective" in this case means short, accurate and recipe based.

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