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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
