[Releasing] Bug priority downgrading during release process

[Ziller Eike]

On 20.12.2012, at 12:49, Linaae Hanne <Hanne.Linaae at digia.com> wrote:

> Hi,
> 
> On Dec 20, 2012, at 11:27 AM, Anttila Janne wrote:
>> One minor thing was bothering me on Qt 5.0.0 release process (beta, rc, and final).  It seems that we are sometimes changing bug priorities during release process to comply with some policy (No P0 or P1 in release). There was also the following statement in "Meeting minutes: Release team meeting Dec 11, 2012" mail:
>> 
>>> 3. Next steps 
>>> * Evaluate all incoming P1s, and consider downgrading if not crucial for 5.0.0. 
>> 
>> For me this makes no sense - bugs should and can be reprioritized based on valid reasons, and the reason should be always written to bug report. Downgrading priority just for sake of policy is stupid, instead those bugs should be targeted for next release with appropriate comment. Downgrading bug priority due to policy opens a possibility that important bug is not fixed to next release either (Downgraded P2 is likely more important compared to bug that was originally evaluated as P2).
> 
> Yes, I agree that the reason for setting a different priority to a bug should always be argued with a valid reason.
> 
> Fact is though, that there will always be bugs in a product. I am sure that we will find P1 bugs in the released 5.0.0 packages. I think most agree that if we are to have time-based releases, and a release is just around the corner, we will be less and less strict about what _has_ _to_ go into the release the closer we are to the release date.
> 
> So question is: Should we downgrade the P1s that we don't think are necessary for a release to get out (of course still stating the reason for changing the priority, i.e. *why* we don't think it is important enough to fix the named bug), or should we just select the P1s that are needed for the release, and keep some out?  By doing the latter, we would sort of be creating a new priority system for the release, I therefore think we need to change the priority of the bug, if that really is what we think about it.

We tend to do what Janne suggests for Qt Creator issues, i.e. if we decide that a bug will not be fixed for the upcoming release even though it is "rightfully" P1, we keep it P1 and set the "Fix version" to the version we think can and should have the fix.
Release management / QA can set their filters to ignore issues that are explicitly targeted for a different version through the "fix version".

Br, Eike

> Other suggestions on how to tackle this in a better way, are welcome.
> 
> Hanne
> 
> 
> _______________________________________________
> Releasing mailing list
> Releasing at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B