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
Stephen> We are going to need workers to enter the issues,
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.
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.
XEmacs-Beta mailing list