Re: wheezy postmortem re rc bugfixing
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
2. Things that must either be fixed or the package removed
3. Not evaluated
4. Will probably ignore, but not ready to make that call yet
If we had additional tags for #1 and #2 to communicate that the release team
has evaluated a bug and concluded it's in the must fix category, then that
would help people trying to fix RC bugs focus on the things that are known
release issues.
I have seen release team discussions on bugs along the lines of "I will
probably ignore that one, but I'm not ready to decide for sure yet". I think
release team members are rationally cautious about applying ignore tags
because once that's done, it's pretty certain no one will look at it. If
there were a tag for will probably ignore then that would both be a clear
indicator for RC bug fixers to perhaps focus elsewhere if it's not easy and
perhaps help the release team avoid having to rediscuss bugs as much.
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.
Scott K
Reply to: