Change release schedule 4.2 and schedule for 4.3

[Michael Pyne]

On Tuesday 09 September 2008, Cornelius Schumacher wrote:
> On Wednesday 10 September 2008 02:35:53 Mauricio Piacentini wrote:
> > Agreed, but how to force them to fix the bugs?
>
> There is no way we can force developers to do anything. But we can try to
> make it easy and rewarding to do so.

I am pretty much super-late to this discussion but I think this is one of the 
points to the summer-in-trunk proposal:

If releases are to come from a "winter" branch then you must not only work on 
developing your feature in the spring/summer branch, but you must then 
stabilize it to permit it to move into autumn/winter branches.  Otherwise that 
shiny new feature you made will never be seen in an actual release.

Right now it is sufficient merely to merge it to trunk during feature 
development phase and postpone stabilization to the freeze (which means 
stabilization is not guaranteed).  If you don't/can't stabilize your software 
and no one else does then either the release will have bugs or (preferably) 
someone will notice and revert the feature if possible.

This relies on there actually being a barrier between developing in a summer 
branch and getting it to "autumn".  It can be a social barrier where 
developers are expected to not merge new features that aren't to that level of 
quality, or it could be something that requires review (although that has 
obvious scalability issues).  It could be different between modules (i.e. 
review required for libs but not apps).

Even if we don't actually implement this new development plan I think it is 
good that we start thinking in terms of ensuring quality in more detail than 
"freezes can only improve quality of code".  i.e. what processes can we do to 
improve quality, and of those processes, which are practical to implement 
without squelching development?

In that regard I like the season-themed branches idea although I would like to 
see the details fleshed out on how we handle merging code from spring -> 
summer -> autumn -> winter branches.

Regards,
 - Michael Pyne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080910/606e4305/attachment.htm>
-------------- 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/20080910/606e4305/attachment.sig>