Re: Unable to find RC bug targets to squash
Le Fri, Mar 01, 2013 at 10:29:49AM +0100, Andreas Tille a écrit :
> I wonder in how far I could do my share in the bug count reduction
> business. Perhaps in helping finding bugs belonging into such
> categories to attract the right people to the right bug and help
> reducing the time for people to detect a reasonable target for
Hi Andreas and everybody,
I agree completely.
During this cycle, my attempts of fixing RC bugs outside our team's packages
have not gone beyond contemplating the list and finding either bugs that are
beyond my level, bugs that can be solved by removing the package from testing,
or bugs that are likely to be solved by the active maintainer of the pacakge.
In the previous release cycles, it looks like the main blocker was the Debian
Installer. As soon as it was ready, lots of remaining buggy packages were
purged from Testing and release followed quite soon. Is that the case for this
release cycle ? If yes, I guess that the focus should be to help the Installer
team, and not to fix every RC bug.
If there could be a list of bugs that, in the opinion of the Release team, are
strictly impossible to solve by removing packages or dequalifying
architectures, then I think that it would motivate more people to block some
time in their agenda and work hard on these focused issues.
A bug sprint like in 2009 is an interesting alternative if there is no way to
prioritise bugs, as it ensures a more efficient dispatching of contributors on
the bugs, see http://wiki.debian.org/BugSprint. (And no, sorry, I do not have
time to organise one in 2013, but if people are interested and nobody steps up,
one could consider using a really random assignment of bugs to participants).
One intersting property of the bug sprint is that it provides incentives to
solve the bug by leadership when the participant does not have directly the
Have a nice week-end,
Tsurumi, Kanagawa, Japan