[Releasing] Bug priority downgrading during release process

Abrahamsen-Blomfeldt Eskil Eskil.Abrahamsen-Blomfeldt at digia.com
Thu Dec 20 14:06:01 CET 2012


---- 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 P2's.
----

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. 

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.

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

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". 

Either way seems better to me than moving bugs back and forth between P1 and P2 at the time of release :)

-- Eskil







More information about the Releasing mailing list