Proposal: Target tracker bugs
beland at alum.mit.edu
Wed Mar 24 19:03:28 UTC 2010
> As we rely more and more on the release criteria and addressing bugs
> that are on the blocker list, I'm seeing a hesitation to fix any
> other bugs in Branched. In some sense this is a good thing, less
> change generally means more stability.
>From a user and tester perspective, I'd like to speak up for the
benefits of getting as many bug fixes as possible into a release. It
wastes a considerable amount of time if people encounter, diagnose,
and report bugs only to be told that they're already fixed. I'm also
a bit concerned about the growing distance between the software people
are running and the bleeding edge where bugs are easiest to fix. It
creates additional complication when we have to discover and diagnose
bugs in one version but then re-test for the same bugs in a newer
version. If things are only fixed on the bleeding edge, it can also
mean that the vast majority of users are always running a version of
the software that's buggy, because fixes take 6-12 months to propagate
into a supported version, but new releases will also have new features
and thus new bugs which will not get fixed in that release. That
said, I do understand the need to balance high bugfix thruput with
stabilizing freezes and continual Rawhide development and testing.
It seems to me that the standard for including bug fixes in Branched
is (or should be) the same as for updates to the final release. That
standard in practice seems to be fairly liberal post-release for
non-critical packages - anything that's been tested and we're
confident helps more than hurts. Of course critical path packages are
held to higher standards, but in the end, it seems almost any suitably
vetted bug fix would be "nice to have" in a milestone release.
In terms of actual workflow, then, I see two classes of bugs - those
that Release Engineering is monitoring closely around release time,
and everything else. From what I hear, the first category includes
both blockers and essentially non-blocking fixes you really want but
which may or may not make it in time. Unless there's a good use case
that would require two lists or a list plus flags, why not include
both "hard" and "soft" blockers on a single monitoring list? I agree
with Adam's leanings - after a blocker meeting determines a bug is a
"soft" blocker, it's sufficient to indicate that in a comment on the
bug. There's no real need for that attribute to be separately
queryable, because for release preparation and scheduling purposes the
whole list is gone through one by one.
If you don't want to actively monitor a bug but do want to encourage
the maintainer to get a fix in as soon as possible, I say the thing to
do is to express that to them in a comment and then de-list the bug.
As regular users and triagers, we have found that adding "F12Target"
to a bug doesn't do anything more than asking nicely if something will
be fixed in Fedora 12. Pretty much any bug will have a supporter who
wishes it would get fixed in the current or next release, but setting
keywords and severity appropriately and adding rationale in comments
is probably a more nuanced and effective way to do that than adding to
a special list. Lacking compelling motivation for more complexity, it
probably makes sense in this case for Release Engineering to use the
same mechanisms as everyone else, even though their requests and
encouragement might carry more weight.
More information about the test