[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
release.
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