[Releasing] Bug priority downgrading during release process

[Roscher-Nielsen Nils Christian]

Hi

> -----Original Message-----
> 
> 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.

I think Janne is completely right, and I also think we should not change the priority of bugs depending on the time. We might choose to release with certain bugs, but if we change the priority we make it a lot harder for ourselves both to understand the quality of our own releases - and implement measures to improve them - as well as we make it harder to properly prioritize what should be fixed after the release is out and we are working on the next iteration of the product. 

As we might lax on our demands for this imminent release, that surely should not mean that we should be less restrictive about how we value code quality in Qt as such. 

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

Technically the not fixed issue would be just as important. If we downgrade it just because of timing, we make it harder for people to understand what to work on after the release, as two issues we initially gave different priority are now suddenly both P2's after the release. 

Also, users and customers are using the bug reporting system to understand the quality of the lead. If the issue is in the release we fool them to think it is less important than it is. The bug tracker is not being used only by the developers of Qt itself, but also the users of Qt to understand our code quality. 

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

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. 
 

Best regards
 Nils Christian Roscher-Nielsen

Sales Engineer - Digia, Qt

Visit us on: http://qt.digia.com