Adam Williamson wrote:
The Target trackers were discontinued, so far as I recall, because
no-
one ever really took a blind bit of notice of them. People would throw
bugs onto the list and then...nothing much would happen. It was just
kind of a wishlist and (IIRC) very few packagers even looked at it, and
even those involved in release wrangling had enough on their plates
just dealing with the blocker list.
That's exactly the problem with such a process with no enforcement. I also
doubt it is going to work.
Blocker review is a rather resource-intensive process, where the
resource involved are of the squishy human kind. I'm not sure anyone
would be super-thrilled about spending several *extra* hours per week
having bunfights about whether an issue is 'critical' or 'important'. I
think if we're gonna go with this it might make sense to use a rather
lighter process than the blocker review process, though I don't have a
specific proposal for how that could look at this point in time. If it
would mainly be used by the FPL and FPM, perhaps it could simply be the
rule that they got to decide what bugs went on it?
Why would this need a centralized process at all? Why not just let the
affected SIG or WG decide?
In fact, I would argue that this should even be done for blockers: A bug
should be a blocker if and only if a SIG/WG behind a release-blocking image
decides that it is important for it to be fixed in the release, no matter
whether it fits into any kind of global formal criteria. And punting
blockers should also only be possible if the responsible SIG/WG agrees with
it. As long as the SIGs and WGs for all release-blocking images have not
signed off on the release, we should slip, even if it takes weeks (and to
avoid long freezes, a slip should consist of accepting ALL pending updates
and restarting the freeze process from scratch – that should also
singificantly reduce the need for freeze exceptions).
Kevin Kofler