On Fri, 10 May 2013 10:03:46 -0400 Scott Kitterman <debian@kitterman.com> wrote: > On Wednesday, May 08, 2013 04:51:14 PM Ian Jackson wrote: > > So I would like to suggest that we should have a thread where we: > > > > * Try to identify the main ways in which bugs can be "hard" (which > > might be technical, political, or a mixture) > > > > * Try to think of workflows which might overcome these problems > > Currently there are formally two classes of RC bugs relative to a release, > ignored and not ignored. Informally not all RC bugs without the $RELEASE- > ignore tag are not the same and I think this ambiguity has been a source of > uncertainty about where people should focus time (this applies both potential > RC bug fixers and the release team, as I see it). > > Stated non-rigorously, active (not ignored) RC bugs can fall into several > bins: > > 1. Things that definitely must be fixed for release A lot of these determinations could be assisted by some simple metrics. From the sidelines of two releases, I've observed that release team decisions on this kind of tag would likely involve things like the Priority of the affected package, it's involvement in existing transitions, the implications of `dak rm -Rn $package` on ries and the history of the package (e.g. if this is going to lead to the fourth NMU on this package since the freeze started). All of that data can be automatically generated as part of the summary of the RC bug or the package itself, then fed into the information visible to developers reviewing the RC bug list. The more of this triage process that can be automated, the more developers can see a standard process being applied and the less work the release team needs to do for every individual RC bug. The release team need the ability to override the calculations but that isn't a problem. The aim, IMHO, would be to reduce the workload by only putting in an override where required or on explicit request by a developer to investigate a particular bug/package. I'd like it to be that only the release team can set the overrides, unlike BTS severity or tags which requests people avoid ping-pong but cannot prevent it. > 2. Things that must either be fixed or the package removed Quite possibly falls out of the triage data for 1. I'd also like this to be tied to some automated removal process, just like the one which was used towards the end of the wheezy freeze. Maintainers ping'd about individual problems with a clear warning that the package is at risk of removal if nothing is done, followed by removal from testing if the bug isn't downgraded or fixed. Again, obvious time limits, clear decisions and processes. > I've stayed away from suggesting any tag names. I think we can adequately > bikeshed that if there's some agreement the added granularity would be worth > the added complexity. I think it would be a useful addition and something which does not need to be restricted to solely within a freeze. We need more of this kind of stuff running constantly (or at least starting a few weeks after the previous stable release), with the time limits being adjusted as we get closer and closer to freeze and then release. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpy_2aiNKCRS.pgp
Description: PGP signature