Re: BHS: Bug help system
On Tue, Mar 25, 2003 at 06:50:15PM +0000, Mark Howard wrote:
[snip]
> - Maintainers have different skills and resources. For example, it may
> take one developer a few seconds to fix a bug in an XSLT stylesheet,
> whereas it may take the packages maintainer much longer. At present,
> maintainers look after all the bugs in their own packages themselves -
> things like sending a note to a mailing list or tagging a bug Help are
> rarely used.
I dunno, I've been triaging a lot of bugs which are not my own (in fact, I
think I should start working on some of my own neglected bugs...), closing
bugs that are fixed but forgotten to be closed, pinging submitters of very
old bugs, submitting patches, etc.. This is mostly in core packages like
glibc and basic utilities; but I've also been hitting on AJT's old bugs
list (http://master.debian.org/~ajt/oldbugs.html) from time to time.
While I *have* used the help tag on my own bugs, you're right in that
people usually don't notice them. But just sending a little note to -devel
afterwards usually works.
> In terms of resources, some lesser-skilled developers may have plenty of
> time to search in upstream bts, or fix typos, but they don't do this
> mostly because it is not advertised that these things need doing
Umm... I thought this is pretty prominently displayed on the front page at
qa.debian.org and in the developer's corner in w.d.o.
> - Maintainers have real lives. At certain times, they can devote lots of
> time to maintaing their packages; at other times they can't. At present
> it seems like most maintainers either take on many packages which get
> plenty of attention when the maintainer has time but are abused (long
> bug lists, long delay between releases) when the maintainer doesn't have
> time; or, they orphan packages when they're too busy and when they get
> time spend it on other (non-Debian) things. Neither of these are
> optimal solutions for the project.
Propose something better, then.
> - New Maintainers want to be part of the Debian community, yet they
> usually start by searching the Internet for yet more trivial packages to
> include in Debian. These are packaged well and kept bug free, but this
> is a relatively simple task. Debian is full of buggy packages - New
> maintainers should prove that they are good enough by helping fix these.
Good idea. Some people have voiced their concern over NM's that only care
for their own little package. It's time to change the still-widespread
perception that becoming DD = becoming package maintainer. I think we need
some NM's who are just interested to fix bugs in existing packages, rather
than introduce new packages.
> They don't as many maintainers hate people messing with their bugs.
> Also, they do not know whether anybody else is actively working on that
> bug report.
Uh, that's what the BTS is for: to record what people have been doing with
that bug. Anyone actively working on a bug should be updating the BTS
accordingly anyway.
> I think we can help the situation by writing a system for tracking
> requests for help. This is kind of like an advanced version of the help
> tag in the bts.
>
> The system would work in a similar way to the bts:
> When maintainers find a bug report which they don't know how to deal
> with / don't have time to deal with / think somebody else could do much
> better *and* they think somebody else might (such as bug #182330 -
> creating a pts icon for galeon bookmark), they would write a control
> email telling the bug help system which bug they want somebody else to
> look at, possibly with their own short description of the problem. This
> request would be sent to one of a number of groups, e.g. graphics, man
> pages, gconf, powerpc, bugzilla_search_masters, c++, make, gtk,
> usability...
How is this different from sending a request for help to -devel (or
other appropriate forums)?
> The bug help system would have a web interface through which all reports
> for each group can be seen.
http://qa.debian.org/bts-help.html
[snip]
> When a developer sees a bug report they are interested in, they will
> send a command to remove it from the bhs listings and start work on the
> bug.
I'm not sure why only one person can work on a bug at a time. Although I
agree it's a good idea to have some sort of tracking to coordinate efforts
between people so that there's not to much duplicate work.
> If the report is more of a request for advice, then bhs subscribers may
> choose to just add comments to the report - this is still helpful for
> the maintainer.
I'm still not sure how this is different from having dedicated mailing
lists and posting requests for help when you need help.
[snip]
> Unlike the bts, the bhs is not a place for old bug reports. If a call
> for help goes unanswered after X days, it will be removed from the list
> so that bhs subscribers don't have lots of uninteresting bug reports to
> look through. The package maintainer will get an email notification of
> this removal and should look into other ways of solving the bug report
> (e.g. asking on a mailing list).
[snip]
Why not ask a mailing list first?
T
--
Alpha-testing: we really don't have a product yet, but since the customer
asked, here's a glue-and-matchsticks model of what we think the product will
be.
Reply to: