emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unable to close a bug in the tracker.


From: Stephen J. Turnbull
Subject: Re: Unable to close a bug in the tracker.
Date: Mon, 18 Jan 2010 13:13:59 +0900

Miles Bader writes:
 > Óscar Fuentes <address@hidden> writes:

 > > The Version Control system must be tailored to developers. The bug
 > > tracker shall be accessible to users as well.

Yup.  Isn't it time to stop making excuses, admit that there really is
a problem here, and either say, "It's too much effort (so don't bother
asking any more)", or fix the bug tracker?

 > Sure, but note that
 > 
 > (1) This is only true of some operations -- users very often _open_
 >      bugs, or give further comment, but other operations are almost
 >      always done by devs

This actually isn't true in Emacs.  Emacs developers have never
hesitated to ask users to do things like provide additional
information, etc, and I have seen requests to add tags on this list.
Although those requests for tracker operations may have been directed
at other developers, *Emacs users do accept responsibility to do
(reasonable amounts of) scutwork* to save developers the trouble.
Isn't it worth paying them back for that?

There are also Emacs developers whose relationship to emacs-devel and
the email-based workflow is very intermittent; they show up briefly
before a release, want to interact efficiently with their package's
bugs (often a newly added one), and are stymied by an unfamiliar or
long-disused UI.  (I know this has repeatedly happened to me in
dealing with debbugs for Debian's XEmacs packages.)

 > (2) How convenient a particular interface (web / emacs / generic email)
 >      is depends on the operation -- commenting on a bug you're already
 >      following (for instance, if you submitted it in the first place, or
 >      are a dev working on it) for instance, is usually far more
 >      convenient via email, even for people that generally prefer web
 >      interfaces (because they can just hit "reply" in their mail reader)

Nope.  It varies by project, and Emacs might be better than most.  But
for bugs I've reported to free-desktop.org, MacPorts, Debian, SuSE,
Fedora, Mailman, and Bazaar, I've almost always had to go to the web
interface for context (previous messages and uploaded files) because
the mail that I get is weeks later, and a laconic one-liner (eg, "I
don't understand") followed by 12 lines of administrivia about bug
status and nosy lists.  And some trackers allow response to specific
messages (specifically, email-based trackers will), so if you don't
save all your bug-related email, you will be unable to determine where
in the thread this particular mail belongs.

Curiously enough, I never need to go to the web interface for XEmacs
bugs.  But I have a funny feeling that's not Emacsen-specific, but
rather developer-vs-user-specific.

 > So I think while a good web interface is important for some operations,
 > it really isn't critical to have one for _all_ operations.  Hopefully
 > that makes the problem a bit easier...

Basically, setting status and priority are the only ones you can leave
out.  Even assigning the bug to a developer should be allowed for
users, because that often speeds up response dramatically.  But
setting status is trivial to implement.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]