Practical solutions to: the new style "mass tirage" of bugs
[ subject changed ]
On Thursday 21 February 2008 8:22:49 pm Don Armstrong wrote:
> On Thu, 21 Feb 2008, David Nusinow wrote:
> > We could deal with this problem if we were better at training and
> > recruiting people to work on such things. We've been lucky in the
> > XSF lately in getting enough hands to get the work done, but I don't
> > think there's any clear forumla from our experience that could guide
> > other teams to do the same. I'd love to find one though. If we could
> > do a better job of steering people towards these important packages
> > rather than their vanity package of the hour, I think everyone would
> > benefit.
>
> I think it's going to be in our long term interest to identify some
> more of these packages that could use help and figure out what changes
> (if any) need to be made to the BTS, documentation for those packages,
> and anything else to help new people get into triaging these bugs.
Excellent points made by both of you.
Here are some things that occur to me quickly:
1) Large projects using $DVCS and making it easy for people that aren't
familiar with $DVCS to learn how to participate in that project. Here I
assume $DVCS to be one of hg, git, darcs, bzr. The "maintainer of record"
in control could be a Linus-like patch reviewer. The instructions are
something akin to what I post at
http://software.complete.org/site/wiki/DarcsGuide and
http://software.complete.org/site/wiki/MercurialGuide
2) Potential ways to assign bugs to particular contributors or subprojects
that don't occur at binary package boundaries.
3) Even better, ways to let that happen at submission time.
4) Integration with BTS and $DVCS. I have some code that marks bugs pending
when mentioned in a VCS change log. But this could go farther: branches
tied to bugs, etc.
5) A way of sorting bugs by "hack on this first". Our priorities are not
necessarily this way. For instance, we may have a wishlist bug to package
the new upstream and a serious bug that is caused by a bug in the current
upstream and may be fixed by the new upstream. Makes sense to do the
wishlist bug first and then test to see if it's gone away. In a sense, we
need a field that means nothing to anybody except the maintainers, and is a
value that the maintainers can use for whatever purpose they like.
6) Better tools to integrate Debian BTS with upstream BTS. I would love a
command-line tool where I could say "debforward 123456". It would look up
the package name for 123456, figure out from some metadata what type of BTS
it uses and where it lives, look up my account on that BTS in ~/.forward,
and create a bug report there and mark the Debian one forwarded. Then, if
there is no automated mechanism, some scanner at Debian would look for
changes on either end and forward them back and forth. I would love this.
It takes a *ton* of time to interact with some HTTP-only BTSs and forward
stuff back and forth.
7) Perhaps even a change of policy on upstream bugs. If the Debian
maintainer is really sure a bug is upstream, it should be a valid response
to close it in Debian with instructions on submitting it upstream and
reopening it in Debian if upstream believes it's a Debian issue. There's a
lot of work just schlepping data between upstream and end users for things
that aren't really Debian issues.
Take this with a grain of salt, as I don't actually maintain any packages of
the scale of OOo/KDE/whatever. Just one that feels big to me. :-)
-- John
Side note: "schlepping" appears to be in KDE's dictionary. wow.
Strangely, "KDE's" isn't.
Reply to: