Re: pretest, devel and bug lists

["Stephen J. Turnbull" <stephen@xemacs.org>]

Nick Roberts writes:
 > Richard Stallman writes:

 >  > I think that is a misunderstanding.  There are two questions here!
 >  > 
 >  > 1. Whether messages people send to bug-gnu-emacs should generate bug
 >  > tracker entries.  (And likewise for emacs-pretest-bug.)
 >  > 
 >  > I said nothing about that, but I think that both lists should do so.
 >  > 
 >  > 2. Whether the bug tracker should send mail to bug-gnu-emacs.
 >  > 
 >  > That is the question I was talking about before.
 >  > I think it should NOT send any mail to bug-gnu-emacs, or
 >  > to emacs-pretest-bug.
 > 
 > What does that mean?

AFAICS, that means that the workflow continues to be organized around
the lists, and that gateway to the bug tracker is used to ensure that
issues get recorded for review.

 > The thread generated by a bug report is presumably a mixture of
 > technical discussion and admin related to the tracker.  How does
 > someone following bug-gnu-emacs know that a bug report has been
 > closed if he only sees part of the thread.

He looks at the bug tracker web interface, or joins the nosy list for
the bug.  (If that's possible, I know debbugs sends mail to the
originator and to the maintainer, presumably there's a way to add
yourself to the list of interested parties.)

This is basically the model used by the Python developers, with the
improvement that the tracker generates a weekly report containing a
summary of activity (total issues, total open, new this week, active
this week, closed this week, etc), a list of new issues with their
titles, and list of closed issues with their titles.  It sends this
report to the mailing list.  This minimizes the intrusion of
administrative detail on the list, while making people aware of the
tracker and its activity, and prompting developers to maintain the
issues that they are responsible for.

So your presumption is wrong, in that model: there is a thread of
substantive discussion on the mailing list, and there is a thread of
administration on the tracker.  The tracker is also responsible for
keeping important data such as test cases and proposed patches, which
are relatively rarely sent to the list.

 >  >     Using emacs-pretest-bug for the bug tracker
 >  > 
 >  > "Using" in this context confuses the two questions,
 >  > since it fails to distinguish the two kinds of use.
 > 
 > That's probably because I am confused.

Well, there certainly are tracker-centric workflows.  Emacs has never
been one, though, and given all the changes that are happening now I
find Richard's gradualist approach to introduction of the tracker to
be both natural and plausible, even though it probably does postpone
taking full advantage of important tracker features indefinitely.