[Releasing] Bug priority downgrading during release process
Motyka Rafal
Rafal.Motyka at digia.com
Fri Dec 21 09:20:54 CET 2012
Hello,
It seems to me that we need to clarify the definition of Priority property we use in JIRA.
Usually there are two concepts used in projects:
1. Priority,
which defines the order in which we should resolve a defect. This can be changed many times to any value.
2. Severity
which defines the impact that a given defect has on the system. This should be set by a reporter and it can be changed when it's incorrect. Assuming that reporters understand the impact, usually there is no reason to change it.
Maybe we could have two separate bug's properties (Severity and Priority) in JIRA?
Best regards,
/Rafal
Rafal Motyka
QE Engineer
Digia, Qt
________________________________________
From: releasing-bounces+rafal.motyka=digia.com at qt-project.org [releasing-bounces+rafal.motyka=digia.com at qt-project.org] on behalf of Turunen Tuukka [Tuukka.Turunen at digia.com]
Sent: Thursday, December 20, 2012 2:19 PM
To: Abrahamsen-Blomfeldt Eskil; releasing at qt-project.org
Subject: Re: [Releasing] Bug priority downgrading during release process
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
>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.
Or need a way to drop such parts that contain P1 bugs (in case they are
add-ons).
>
>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
>particular release.
Sounds feasible.
>
>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 :)
Definitely.
Yours,
Tuukka
>
>-- Eskil
>
>
>
>
>_______________________________________________
>Releasing mailing list
>Releasing at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/releasing
_______________________________________________
Releasing mailing list
Releasing at qt-project.org
http://lists.qt-project.org/mailman/listinfo/releasing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/releasing/attachments/20121221/7e49c0fd/attachment.html>
More information about the Releasing
mailing list