Change release schedule 4.2 and schedule for 4.3

Aaron J. Seigo aseigo at kde.org
Tue Sep 9 23:36:34 BST 2008


On Tuesday 09 September 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.
> Another issue that is part of our current development is the fact that the
> current development model very much enforces a group dynamic that is 
> pretty beneficial for KDE.

> IMHO the current development model regularly puts much bigger pressure onto
> each developer to show commitment right in time to reach each mile stone.

that won't change.

> Everyone has got to swim with the group and follow the herd instinct.
> The only other alternative would be to make a bold decision and "opt-out"
> (and I know that a lot of people don't like to take the action to "opt-out"
> as this would require additional arrangements and would equal failure of
> their personal goals).

unless i "whip" the team with reminders about bug report counts, etc... people 
do exactly what you suggest they don't. maybe the plasma team is lazy and 
socially non-comformist ;)

> The proposed always-summer-in-trunk model rather is an "opt-in" model which
> allows the group to become much more loosely bound "together". 

as Thiago already noted, you're discussing social dynamics here which should 
not be changed and which are not being proposed to change.

the idea is not, despite what some people in this thread are suggesting, to 
"Forget about releasing". it's about how to release *and* develop with 
increased efficiency and quality in both directions.

the social dynamic of "making releases rock" must be retained no matter what.

> - lots of small "hurd" sub projects ... (which take long to develop but
> don't deliver releases that are relevant for the end-user).

for many projects, the new scheme will look just like the old one.

for project like plasma .. have you read my email describing 
Spring/Summer/Autumn? if so, what did you think?

and how would you envision marble working with the new scheme? (seriously: if 
the new scheme was adopted, what would you do with marble?)

how does it work, in reality, right now?

(e.g. let's stop talking in general terms about possible this and possible 
that and start talking about our experiences right now, today with our own 
real projects. note how i've been talking about Plasma, Thiago about Qt ...)

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


More information about the kde-core-devel mailing list