On 20.12.2012, at 12:49, Linaae Hanne <[email protected]> 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 > [email protected] > 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 _______________________________________________ Releasing mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/releasing
