Change release schedule 4.2 and schedule for 4.3

[Sebastian Kügler]

On Tuesday 09 September 2008 20:54:22 Boudewijn Rempt wrote:
> Right now, having the boring work, i.e., making it into a release, depends
> on you also participating in the stabilistation phase, trunk-is-always open
> rewards the opposite: have fun. do cool stuff, never care about integration
> or stabilisation, just blog and be famous.

It's supposed to be the other way round. Currently, the only fairly hard 
policy is 'don't break the build in trunk', but it's OK to commit unfinished 
features there. Only for larger chunks of code, there's a review process in 
place (through kdereview, meaning "if people are quiet for two weeks, or 
nobody cares to review your code, it'll go in unreviewed" -- not ideal if you 
want to prevent regressions -- often it doesn't even make sense to review 
what's in trunk (at least you never know, because it's OK to commit unfinished 
things into trunk). At freeze time, nobody cares about reviewing it anymore as 
it's in for some time already.

With the new model, we'd have stricter rules to commit to trunk ("no 
regressions", has to be "ready", <more>) so you'll get the "if you want it 
merged, you need to finish it (and preferably maintain it forever)". That way 
you discourage the antisocial behaviour you're describing. This effect is 
actually pretty common in Free Software projects. Once your code is in, the 
motivation to polish it decreases.
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080910/6a279dd4/attachment.sig>