[Development] Release branch change criteria

Laszlo Papp lpapp at kde.org
Sat Jun 29 20:09:17 CEST 2013


I agree ...

Laszlo


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
> 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
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130629/bebce606/attachment.html>


More information about the Development mailing list