[Releasing] Bug priority downgrading during release process

[Linaae Hanne]

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.

Other suggestions on how to tackle this in a better way, are welcome.

Hanne