Change release schedule 4.2 and schedule for 4.3

[Sebastian Kügler]

On Tuesday 09 September 2008 11:42:07 Cornelius Schumacher wrote:
> > Anyways, as someone asked (maybe you?)
> > during sebas' presentation, not everyone does bugfixing even now, it
> > depends on several factors, on each one's sense of responsability, and on
> > each one's schedule. And we are just blocking potential contributions.
>
> This seems to be a bit shortsighted. We can't take contributions for the
> prize of not being able to stabilize the code for a release anymore. So
> what might be perceived as blocking might be the most important measure to
> actually do a release of our code.

For what it's worth, I don't think this gives an accurate picture of the -- 
rather complex -- situation. With the plans Dirk and I have been advocating at 
Akademy, we *will* have more freedom to release because the development 
process is different from the release / stabilization process. So it addresses 
the issue that is underlying to this whole discussion.

The most important issue we need to solve is that we actually need to take 
care of our releases' stability. And that's also nothing new. There is no easy 
solution to this, but I believe a number of smaller steps and measures to 
ensure that people do not take the 'summer in trunk' model as an excuse to not 
have to do bugfixing anymore. We could, for example, have a separate branch 
that works exactly like the old model, so for the lazy peeps that don't have 
problems with the codebase being frozen regularly (or rather changing status 
under their feet), they could follow a "traditional tree" (for example a git 
branch that is switched from trunk/ to the release branch when this branch is 
created, emulating the current model). Also, by not allowing active 
development in trunk/, it will actually be *easier* to stabilize, since, 
assumingly less bugs are in trunk. We also need a stricter set of rules when 
something is actually allowed into trunk, probably taking the policy we 
currently apply and see if something like this would work for trunk as well). 
At the same time, we'll improve the tools that make it easy not to do 
development in trunk and to merge and test bugfixes (easier branching), and to 
review each other's code (this is another process that is really painful right 
now). Benjamin has a well-written analysis of this process on his blog, surely 
worth reading: 
http://benjamin-meyer.blogspot.com/2008/08/code-review-should-be-free.html

So the issue is quite a bit more involved then "summer in trunk will make it 
impossible to release".

In this thread, the thing that is becoming increasingly clear is that there's 
a wide variety of stakes in KDE's release and development process:

- some want a release based on Qt 4.5 quickly
- some want longer development cycles
- some want shorter development cycles
- some want sprints with free hacking during a planned freeze
- some want alignment with the freeze to Akademy
- some want alignment with KDE releases to downstream distros
- everyone seems to see the code freeze as necessary evil

In our current situation, we're totally lacking the flexibility to account for 
these various stakes. This is exactly what the havoc in this thread is about.

We have become too diverse for the current, rather limited development model 
and tools. We need a more flexible model and better tools to make KDE's 
development scalable and suitable for everyone involved.
-- 
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/20080909/94610eb1/attachment.sig>