[Releasing] Bug priority downgrading during release process
Tuukka.Turunen at digia.com
Thu Dec 20 14:19:25 CET 2012
On 20.12.2012 15.06, "Abrahamsen-Blomfeldt Eskil"
<Eskil.Abrahamsen-Blomfeldt at digia.com> wrote:
>---- Nils Christian Roscher-Nielsen wrote:
>Keep P1s as P1s, and make a note in the Known Issues page or change log
>etc to document all P1's in the release. With a time based
>release schedule we will always have issues we don't have the time to
>fix. IMHO we need to be honest about that, and not pretend they are only
>I agree with this. The idea that we can't have P1s in Jira and do a
>release is a left-over from quality-based releases. We want to do
>time-based releases, which means we won't fix all P1s for the release.
Or need a way to drop such parts that contain P1 bugs (in case they are
>Changing the priority to P2 is just a way to hide that fact from
>ourselves because we feel uncomfortable with the concept of time-based
>releases, and it just means we have to temporarily adjust the priority to
>P2 and then back to P1 when we start working on the next patch release.
This is not entirely accurate. Sometimes bug priorities need to be changed
because of the original estimate being incorrect. Very often the original
estimate is done by one person, so naturally we need to be able to adjust,
if needed. Adjusting when needed is better than not being able to set
priorities without a committee.
I completely agree that it makes no sense to make P1 a P2 if the reason is
to be able to release. For those cases I remember that has not been the
reason, but rather there has been a bug someone has reported as P1 that is
not considered a P1 by a larger group triaging the bugs.
Clearly we need to define the policy of this better than it now is.
>I think we should make an effort to fix as many P1s as possible. The ones
>that we cannot fix in time, should remain P1, but the "version for fix"
>should be either left blank or set to the next release after the current
>one depending on how much the developer would like to promise. A release
>would then be blocked only by P1s and P0s which are scheduled for that
>Another solution would be to add a new level of prioritization. If we
>moved all current P2s to P3 (and so on) and did some renaming so they are
>understandable, we could add P1 as a level between P0 and the current P1
>which basically means "unreleasable but not as urgent as P0".
I do not think this is a good approach.
>Either way seems better to me than moving bugs back and forth between P1
>and P2 at the time of release :)
>Releasing mailing list
>Releasing at qt-project.org
More information about the Releasing