[Development] Release branch change criteria
lpapp at kde.org
Sat Jun 29 20:09:17 CEST 2013
I agree ...
On Sat, Jun 29, 2013 at 1:18 AM, Thiago Macieira
<thiago.macieira at intel.com>wrote:
> I'm seeing lots of changes going into the release branch that I really
> 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
> 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
> 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.
> extra step is to make us think whether the change is really important for
> 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
> 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
> Development mailing list
> Development at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development