Change release schedule 4.2 and schedule for 4.3

[Thiago Macieira]

Aaron J. Seigo wrote:
>how does it work, in reality, right now?

Ok, this is about how Qt development has happened for the past few years, 
using Perforce. This is before Git, this is no longer the scheme we are 
using right *now* (we're in state of flux).

First of all, Perforce is better than SVN at merge-tracking. What SVN 
delivered only in 1.5, Perforce has had for years and it has allowed this 
process to work. But, unlike SVN and Git, Perforce doesn't allow you 
to "switch between branches". You have to have two checkouts: one per 
branch.

It starts with qt/main (a branch). At one point in time, the release 
manager will declare feature freeze and branch. It's the same thing and 
happens at the same time.

At that time, we have qt/main and qt/4.x (qt/4.0, qt/4.1, qt/4.2, qt/4.3, 
qt/4.4; there'll be no qt/4.5). All developers change their p4 client 
specifications and check out the new branch.

One branch is frozen, the other is not. However, developers are instructed 
to start working on stabilisation.

Tasks are fixed in the qt/4.x branch, committed and then the developer 
runs a simple script called "p4i" that cherry-picks the change into 
qt/main. That way, everything that happens in qt/4.x is also present in 
qt/main.

At another point in time, we reach release time: qt/4.x.y is branched off 
qt/4.x. That branch is off-limits to all developers: only the release 
manager commits there. We have several rounds of testing (called Black 
Team), where our developers try to break Qt and find all issues to the 
baseline quality. Until we're convinced we've met the quality 
requirements, we stay in this cycle: build packages, test, report issues, 
fix them, Release Manager integrates them into the release branch.

The qt/4.x.y cycle is repeated a few times, usually on a time-triggered 
process, for each patch-level release.

In the meantime, qt/4.x is still there, but turns into post-release 
status.

For the next months, attention progressively shifts from qt/4.x to 
qt/main. Small and medium-sized features are developed in qt/main, that's 
also where non-severe bug fixes go (the qt/4.x branch's policy allows 
fixing only of crashes, regressions, data loss, bad behaviour, nasty 
stuff).

Large-sized features are developed in branches. They are merged into 
qt/main before the next feature freeze.

The problems with this model are:
 * features are all merged in the two/three weeks leading to the feature 
freeze
 * the automated test system does not check the feature branches, so their 
merging is very destabilising
 * in any case, since everyone is using and testing qt/4.x, qt/main is 
allowed to drift and test regressions creep in

The new model is meant to fix those problems.

-- 
  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/20080910/6a07fe41/attachment.sig>