[Development] Release branch change criteria

Thiago Macieira thiago.macieira at intel.com
Sat Jun 29 00:18:13 CEST 2013

I'm seeing lots of changes going into the release branch that I really can't 
understand why.

In general, those changes seem to fall into three categories:
 1) fixes for showstoppers
 2) fixes for important issues that we'd like to get released ASAP, if possible
 3) changes I could not understand the reason for

In other words:
 1) P0 ("Blocker") and P1 ("Showstopper")
 2) P2 ("Important")
 3) ?

So I'd like to propose the following:

Every change to the release branch MUST have a Task-number associated and said 
task number must be classified as P0 to P2. Changes without Task-number or 
whose task are P3 or lower must be rejected and bounced off to "stable".

If you find an issue that is important and you'd like fixed in the upcoming 
release, but there's no task for, open a task and classify it P0 to P2. This 
extra step is to make us think whether the change is really important for this 

I'm saying that because I know I am guilty of some changes to release that 
shouldn't have been there, on second thought. I am also the author of a couple 
of build fixes, which are technically P1 or P2, but there was no task 
associated explaining why they are P1 or P2.

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130628/c69f6089/attachment.sig>

More information about the Development mailing list