related to an XEmacs BTS

[stephen at xemacs.org]

Mats Lidell writes:

 > >>>>> Stephen wrote:
 > 
 > Stephen> However, if we make any serious effort at entering
 > Stephen> outstanding reports, say from the last year, I'll bet we can
 > Stephen> easily get a couple hundred issues.
 > 
 > How about the strategy of just entering new bugs and old bugs that the
 > bug reporter feels like should go into to bug tracker.

That's fine.  I wasn't advocating "everything since 2005-11-01"
specifically as strategy, but I consider that very desirable, and
would like to push it back to mid 2003 or so if possible.

With Roundup, entry of old mailing list posts as issues is trivial,
too.  Of course that's unlikely to give appropriate priority or
keywords.

 > Stephen> We are going to need workers to enter the issues, classify
 > Stephen> and prioritize them, identify duplicates, link issues to
 > Stephen> relevant mailing list threads, and close fixed, bogus, or
 > Stephen> unfixable issues.
 > 
 > These are tasks that need to be done if you handle bugs whatever
 > system, manual or automated, is in use!?

Sure.  But the current way of "handling" them is "each hacker keeps a
private list, typically in his head".  That's very little work. :-)

 > To me that seems essential for every developer to care about.

What do you mean by "that seems essential"?  The spiel that we send to
new reviewers and package maintainers says "when you're active, read
xemacs-beta and act on stuff you know about," naming the package
explicitly for package maintainers.  On that definition, I have no
complaints about anybody on the board or in the package maintainers.
However, http://www.xemacs.org/Develop/jobs.html says that the "patch
tracker must ensure that no patch falls down a crack".

There's a big gap between those two!  (Note that we do not have
anything resembling an active patch tracker at the moment.)  When I
called for volunteers, I meant I want people who will commit to
putting effort into significantly narrowing that gap.