Change release schedule 4.2 and schedule for 4.3

[Torsten Rahn]

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. 
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).
 
The proposed always-summer-in-trunk model rather is an "opt-in" model which 
allows the group to become much more loosely bound "together". "Opting in" 
would require to take action and make a decision (which people try to avoid if 
possible).  And deciding whether code is ready for release to "opt-in" always 
meets concerns like: "Is my code even ready yet?", "But I imagined this new 
nice refactored frame work soooo much bigger in my dreams ... " and give lots 
of excuses why one should just "skip this round". As there would be no action 
to be taken to "not opt-in" this "step" would be an easy one.
 I'm pretty sure that this would result in 

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

Regards,
Torsten
 

> Of course there are limitations and tools which could be better, but I
> think it's very important to recognize the value of what we have right now,
> and there are a lot of details which have developed over the years, but are
> easy to overlook when only thinking about the big picture. Changing a
> development model can do a lot of harm and alone the fact of changing
> something is a disruption to many contributors.
>
> So I would be much more happy, if the discussion would be lead from a point
> of view that we have a great development model which has proven itself and
> was adapted over the years, and we look how we can iteratively improve it
> even further.