Change release schedule 4.2 and schedule for 4.3

[Thiago Macieira]

Tom Albers wrote:
>I hate to fload the mailinglist. 

Don't worry. This discussion is very healthy and very important. Better 
everyone voiced their opinions.

>But I agree completely with Boudewijn. 
> I think these are valid concerns and I don't really see this
> git/always-summer be a magic solution to our problems.

It's not a magic solution. It's just a step in the right direction.

>As long as our users use another branch than what we developers use, I'm
> likely to vote against that plan. I think the only way to make awesome
> releases is to actually use what the users use. So you get annoyed with
> the same bugs at the same time (or rather a bit earlier).

I've always used and developed trunk only, for the past 8 years now (since 
KDE 2.1). That means I've never used what our users use for the past 8 
years, save for brief periods.

In fact, I'd bet most of our kdelibs and kdebase developers use trunk 
themselves and are, therefore, in the same situation as I am.

That means if any of us do fixes, we have to *backport* it to the stable 
branch. But we don't get to run that stable branch often.

It would be better if all developers used the stable branch, fixed bugs 
there, and instead *forward-ported* to the unstable branch. Same for the 
features: they'd be developed on top of the stable branch, but merged 
into the unstable one when done.

When we reach feature freeze, the labels simply change: stable 
becomes "legacy", unstable becomes stable and a new unstable is branched.

Interestingly, that's the model we have right now for Qt and we're moving 
away from it. The reason being that the unstable/trunk/main branch 
becomes very broken because people aren't caring for it. So we have to 
repeat the stabilisation work over and over again.

Our solution is to continuously run tests and catch problems very early 
on: if a commit or set of commits introduces a unit test failure, it is 
rejected. The developer has to fix the problem before the code is allowed 
in. Unfortunately, I don't see that happening soon to KDE, especially 
since unit testing doesn't really work in KDE (it's more of integration 
testing).

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080909/32ac788a/attachment.sig>