Unable to close a bug in the tracker.

Unable to close a bug in the tracker.

[Karl Fogel]

I committed a fix to bug #5276.  Closing the bug report, however, is
another matter.  I sent mail to <5276-done {_AT_} debbugs.gnu.org>, but
my mail does not appear to have had any effect -- it hasn't shown up in
the bug log, and hasn't closed the bug.

Now I'm going to rant.

For a project like Emacs, a bug tracker whose primary interface is email
is borderline useless.  I mean, look at:

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5276

Does the web page UI offer any of the following basic functionality:

  - A way to comment on the bug?
  - A way to change a status of the bug, including closing it?

No.  But it does stimulate the user to wonder about various questions
whose answers, if the user knew them, would be pointless anyway:

  * What is "Toggle useless messages" for?
    (Please don't answer that.  I don't care what the answer is; I just
    care that there's a UI element offering to "toggle useless messages".
    Might as well have a button labeled "Do not click here.")

  * Why would I want to "View this report as an [mbox folder],
    [status mbox], [maintainer mbox]"?  Who is this aimed at?  Certainly
    not the developer.  Nor the reporter.  Nor testers.  Is there anyone
    among the primary users of a bug report who is served by this?

  * Why does the bug report *start* by default with "Message #3"?
    If message numbers aren't going to make sense anyway, better just
    not to display them.

  * Why does the bottom of the bug report say "Last modified: Wed Jan 13
    23:51:14 2010", when the most recent visible activity in the bug
    dates from 6 October 2009?  Maybe if I toggled useless messages, I'd
    see what this other activity was?  <...tries it...>  Nope.  I guess
    they really are useless.  How reassuring.

  * "To reply or subscribe to this bug, see [here]."  Oh, maybe it's
    using the verb "reply" where most other trackers say "comment" --
    maybe these are instructions on how to leave a comment!  So I have
    to *leave the bug page* to go somewhere else to get instructions on
    how to take one of the most basic actions one can take on a bug?
    These sorts of things are normally done with self-explanatory UI
    elements.

In addition to these problems with an individual bug page, there are
more important general problems with the system as a whole:

  1) While it's great to *offer* email as an option for manipulating the
     bug tracker, it's horribly wrong to *require* it.

     Email interfaces are inevitably experts-only interfaces, because
     the UI is owned by the user's mail client, not by the bug tracking
     software.  So the user has to learn a lot of things by rote before
     she can do anything.  Perhaps the user will become much more
     efficient at using the bug tracker once she has learned those
     things -- rather like Emacs itself, in this respect -- but the vast
     majority of users (both reporters and developers) do not have the
     time or mental space to become experts.  I know I don't.

  2) You request an action but you never know when it will complete,
     because it's subject to the whims of email delivery.  

     Remember that, unlike other network protocols, email is actually
     getting *less* reliable over the years, thanks to the spammers and
     the filters we set up in response to them.  Email delivery time is
     now highly variable, and getting more so.  Non-arrival is not only
     possible, but in some cases common.

     Because you don't know when your action will complete, you may be
     blocked for your actions after that.  This is another way of saying
     that an email-based bug tracker cannot honor the UI principle that
     response time is the most important feature.

  3) Although the web UI could, in theory, give instructions on how to
     change the state of the bug, in practice it doesn't.  You have to
     guess at how to change the state, or you have to poke around the
     site, at which point you run across Dostoyevskeyan novels like:

       http://debbugs.gnu.org/Developer#closing
       http://debbugs.gnu.org/Reporting.html#pseudoheader

     My eyes would glaze over were they not awash in tears already.

  4) If you're not subscribed to a bug via email, then manipulating it
     by email involves lots of cutting-and-pasting from browser to mail
     client (i.e., bug number, bug subject, etc).  The response "sure,
     but you're supposed to be subscribed to the bug and do everything
     by email" should be taken out and shot preemptively, of course.  It
     is, again, not practical for non-experts, nor even for experts who
     have just found a bug (via the web) and want to interact with the
     bug starting now.

The Emacs bugtracker is a major drag on my ability to process bug
reports for packages I maintain.  Either I am not alone, or everyone
else is insane.  I trust it is the former.  There is a reason no one
else uses a bug tracker like this (the Debian Project doesn't count:
they are a OS distribution, not an application project, and anyway I've
had to interact with Debian's tracker and it sucks there too, for the
same reasons).

For the love of Cthulhu, why are we using this monstrosity when there
are so many other good trackers out there?  (Launchpad's comes to mind,
but we could also use a library card catalog system with child labor to
run the bug reports slips back and forth.  Or maybe a system where we
put all the bugs in a file, print the file, take a photograph of the
printout, beam the photograph into space, and count on inventing faster
than light travel some day so we can get out ahead of it, recapture the
data, and use time travel (which is about to be invented) to send the
data back to us along with a bug tracker humans can actually use.

While I've been writing this, my closure message to bug #5276 has still
failed to arrive.  The bug report remains open.

-Karl

Re: Unable to close a bug in the tracker.

[Miles Bader]

Karl Fogel <kfogel@red-bean.com> writes:
> For the love of Cthulhu, why are we using this monstrosity when there
> are so many other good trackers out there?

Hm, is that really true?  It seems more like there are so many other
_bad_ trackers out there.

The ones that do email well, screw up the web interface (or don't have
one).  The ones that do the web well screw up the email interface (or
don't have one).  Some screw both up.  Blah blah...

-Miles

-- 
Optimist, n. A proponent of the doctrine that black is white.

Re: Unable to close a bug in the tracker.

[Chong Yidong]

Karl Fogel <kfogel@red-bean.com> writes:

> I committed a fix to bug #5276.  Closing the bug report, however, is
> another matter.  I sent mail to <5276-done {_AT_} debbugs.gnu.org>, but
> my mail does not appear to have had any effect -- it hasn't shown up in
> the bug log, and hasn't closed the bug.

You're in the "automatically accept" list, so your messages should go
through to the bug tracker without moderation.  But I don't see it in
the debbugs-submit archive.  Strange; I'll investigate.


Some of your criticisms boil down to "the bug page displays too much
information which is distracting to users".  Fair enough, I'll take a
look at whether we can hide some of this information.  (Though, to my
eyes, the average Emacs bug page is a lot less intimidating looking
than, say, than average Launchpad bug page, which has about ten times
the number of "angry fruit salad" links, so tastes clearly differ.)

Re: Unable to close a bug in the tracker.

[Karl Fogel]

Miles Bader <miles@gnu.org> writes:
>Karl Fogel <kfogel@red-bean.com> writes:
>> For the love of Cthulhu, why are we using this monstrosity when there
>> are so many other good trackers out there?
>
>Hm, is that really true?  It seems more like there are so many other
>_bad_ trackers out there.

Yes, I believe it is really true.  I've used a lot of trackers (as I'm
sure you have), and none discourage me the way this one does.

I'm sure there are user demographics for whom it is the right solution
-- Debian Developers are probably one such!  But Emacs developers are
not.

>The ones that do email well, screw up the web interface (or don't have
>one).  The ones that do the web well screw up the email interface (or
>don't have one).  Some screw both up.  Blah blah...

I've seen some that do both well (Launchpad is one, there may be
others).

Re: Unable to close a bug in the tracker.

[Glenn Morris]

Chong Yidong wrote:

> You're in the "automatically accept" list, so your messages should go
> through to the bug tracker without moderation.  But I don't see it in
> the debbugs-submit archive.  Strange; I'll investigate.

It looks like these mails were accidentally discarded. :(

/var/log/mailman/vette

Jan 13 18:59:53 2010 (17350) debbugs-submit: Discarded posting:
        From: kfogel@red-bean.com
        Subject: Re: Doc string of bookmark-bmenu-execute-deletions
        Reason: No reason given
Jan 13 18:59:53 2010 (17350) debbugs-submit: Discarded posting:
        From: kfogel@red-bean.com
        Subject: Re: 'd' and 'x' does not work in bookmark list
        Reason: No reason given

Re: Unable to close a bug in the tracker.

[Karl Fogel]

Chong Yidong <cyd@stupidchicken.com> writes:
>You're in the "automatically accept" list, so your messages should go
>through to the bug tracker without moderation.  But I don't see it in
>the debbugs-submit archive.  Strange; I'll investigate.

Thanks.

>Some of your criticisms boil down to "the bug page displays too much
>information which is distracting to users".  Fair enough, I'll take a
>look at whether we can hide some of this information.  (Though, to my
>eyes, the average Emacs bug page is a lot less intimidating looking
>than, say, than average Launchpad bug page, which has about ten times
>the number of "angry fruit salad" links, so tastes clearly differ.)

I don't think that's the important part.  The distractions on the page
are just distractions -- annoying, but they can be ignored.  The more
important part of my criticism is in the "general problems with the
system as a whole" section, especially the uncertain response time and
unreliability, and the lack of clear UI for manipulating bug states.
Those are killer.

Tastes do differ, but if you did a user survey, or user testing, which
do you think would come out ahead?  :-)  I mentioned Launchpad only
because it's one of the few that offer both web and email UI (and does
both well, IMHO), and therefore is a proof-by-existence that it doesn't
have to be this way.  We could use Bugzilla and still come out ahead.

Is there any convenient way to get access to the full bug database?
Like, all the mbox files, or something like that?  I'd be interested in
getting that, if so, to do a little statistical trawling.

-Karl

Re: Unable to close a bug in the tracker.

[Karl Fogel]

Glenn Morris <rgm@gnu.org> writes:
>Chong Yidong wrote:
>> You're in the "automatically accept" list, so your messages should go
>> through to the bug tracker without moderation.  But I don't see it in
>> the debbugs-submit archive.  Strange; I'll investigate.
>
>It looks like these mails were accidentally discarded. :(
>
>/var/log/mailman/vette
>
>Jan 13 18:59:53 2010 (17350) debbugs-submit: Discarded posting:
>        From: kfogel@red-bean.com
>        Subject: Re: Doc string of bookmark-bmenu-execute-deletions
>        Reason: No reason given
>Jan 13 18:59:53 2010 (17350) debbugs-submit: Discarded posting:
>        From: kfogel@red-bean.com
>        Subject: Re: 'd' and 'x' does not work in bookmark list
>        Reason: No reason given

Thanks for investigating.  Do we have any logs of how many people this
happens to?

Re: Unable to close a bug in the tracker.

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> It looks like these mails were accidentally discarded. :(
>
> /var/log/mailman/vette
>
> Jan 13 18:59:53 2010 (17350) debbugs-submit: Discarded posting:
>         From: kfogel@red-bean.com
>         Subject: Re: Doc string of bookmark-bmenu-execute-deletions
>         Reason: No reason given
> Jan 13 18:59:53 2010 (17350) debbugs-submit: Discarded posting:
>         From: kfogel@red-bean.com
>         Subject: Re: 'd' and 'x' does not work in bookmark list
>         Reason: No reason given

I think I know what happened.

One of the moderators probably clicked on the button for "Add
kfogel@red-bean.com to the list of automatically accepted posters"
(since he's now on that list).  But, at the same time, the moderator
accidentally clicked on the button to discard those two particlar emails
he'd sent.

Anyway, sorry about that, Karl.  If you send again, your emails should
go through without any further problems.

Re: Unable to close a bug in the tracker.

[Glenn Morris]

Karl Fogel wrote:

> For a project like Emacs, a bug tracker whose primary interface is
> email is borderline useless.

When we were searching for a bug tracker, one whose primary interface
was email was one of main criteria, if not the main issue.

>   * What is "Toggle useless messages" for?
>     (Please don't answer that.  I don't care what the answer is;

It's easy to remove this button from the display, but it's sometimes
useful, and does not seem that big of a deal.

>   * Why would I want to "View this report as an [mbox folder],
>     [status mbox], [maintainer mbox]"?  Who is this aimed at?

People who want to download the raw report.

>   * Why does the bug report *start* by default with "Message #3"?

Because of the useless messages which you don't care about, I think.

>   * Why does the bottom of the bug report say "Last modified: Wed Jan 13
>     23:51:14 2010", when the most recent visible activity in the bug
>     dates from 6 October 2009?

It's the date the page was generated. It's a bit useless I agree.

>   * "To reply or subscribe to this bug, see [here]."

This used to be a mailto link, but I changed it in an effort to stop
the tide of spam.

>   3) Although the web UI could, in theory, give instructions on how to
>      change the state of the bug, in practice it doesn't.

We've had numerous explanations on this list, and I have tried to
write notes in admin/notes/bugtracker. Once you get used to it, it's
fairly straightforward, I think.

>   4) If you're not subscribed to a bug via email, then manipulating
>   it by email involves lots of cutting-and-pasting from browser to
>   mail client (i.e., bug number, bug subject, etc).

Or you can use those "mbox" buttons to download a mail to which you
can then reply.

Re: Unable to close a bug in the tracker.

[Chong Yidong]

Karl Fogel <kfogel@red-bean.com> writes:

>>Hm, is that really true?  It seems more like there are so many other
>>_bad_ trackers out there.
>
> Yes, I believe it is really true.  I've used a lot of trackers (as I'm
> sure you have), and none discourage me the way this one does.
>
> I'm sure there are user demographics for whom it is the right solution
> -- Debian Developers are probably one such!  But Emacs developers are
> not.

Why do you say that it is the right solution for Debian developers but
not Emacs developers?  Speaking for myself, I find it pretty convenient
that I can easily manipulate bugs from within Emacs itself (including
CC'ing both individuals and, when necessary, emacs-devel).

Re: Unable to close a bug in the tracker.

[Karl Fogel]

Chong Yidong <cyd@stupidchicken.com> writes:
>One of the moderators probably clicked on the button for "Add
>kfogel@red-bean.com to the list of automatically accepted posters"
>(since he's now on that list).  But, at the same time, the moderator
>accidentally clicked on the button to discard those two particlar emails
>he'd sent.
>
>Anyway, sorry about that, Karl.  If you send again, your emails should
>go through without any further problems.

Thank you.  Yeah, that's a well-known bug in the Mailman moderation
interface (I don't know if that's what the moderator is using, but it
sounds like, since I've made that mistake in Mailman before too :-) .)

Re: Unable to close a bug in the tracker.

[Karl Fogel]

Chong Yidong <cyd@stupidchicken.com> writes:
>Why do you say that it is the right solution for Debian developers but
>not Emacs developers?  Speaking for myself, I find it pretty convenient
>that I can easily manipulate bugs from within Emacs itself (including
>CC'ing both individuals and, when necessary, emacs-devel).

Hmm.

Well, I doubt this conversation is profitable for either of us.  If you
can use that tracker and think it's the right tool for Emacs development
in general, as opposed to you in particular, then we're probably
starting from too far apart when it comes to UI.  I believe you when you
say you like it, but then, a high up-front investment in learning Yet
Another Tool is probably worth it for you.

Re: Unable to close a bug in the tracker.

[Karl Fogel]

Glenn Morris <rgm@gnu.org> writes:
>>   3) Although the web UI could, in theory, give instructions on how to
>>      change the state of the bug, in practice it doesn't.
>
>We've had numerous explanations on this list, and I have tried to
>write notes in admin/notes/bugtracker. Once you get used to it, it's
>fairly straightforward, I think.

A bug tracker that has to be explained on a mailing list or in separate
notes has (almost by definition) a failing UI.

I never have to read the documentation for other bug trackers I use,
because it's obvious how to use them.  If that doesn't seem like a major
win to you, I'm not sure what else to say... :-).

Re: Unable to close a bug in the tracker.

[Glenn Morris]

Karl Fogel wrote:

> I never have to read the documentation for other bug trackers I use,
> because it's obvious how to use them.  If that doesn't seem like a major
> win to you, I'm not sure what else to say... :-).

I think it may be a cultural difference. Emacs bugs have always been
reported and discussed by email. All the tracker really does is hook
that up to a database so that things don't get forgotten about.

All the submitter has to do is use M-x report-emacs-bug. This
initiates an email exchange with the developers. The submitter doesn't
need to know any of the details about the tracker. Only the developers
are really expected to close and tag things (though if others want to,
that's fine). It does require a bit of an investment to figure out how
it works.

I think developers are expected to subscribe to bug-gnu-emacs and keep
an eye out for bugs that are relevant to them.

Browsing bugs on the web and clicking on them to add comments isn't
really what it was designed for.

I'm certainly not debbugs #1 fan, but now that we've finally been able
to tweak it a bit, I'm fairly happy with it.

Re: Unable to close a bug in the tracker.

[Óscar Fuentes]

Karl Fogel <kfogel@red-bean.com> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>>One of the moderators probably clicked on the button for "Add
>>kfogel@red-bean.com to the list of automatically accepted posters"
>>(since he's now on that list).  But, at the same time, the moderator
>>accidentally clicked on the button to discard those two particlar emails
>>he'd sent.
>>
>>Anyway, sorry about that, Karl.  If you send again, your emails should
>>go through without any further problems.
>
> Thank you.  Yeah, that's a well-known bug in the Mailman moderation
> interface (I don't know if that's what the moderator is using, but it
> sounds like, since I've made that mistake in Mailman before too :-) .)

The moderator was me. Your messages were mixed into a long batch of
spam, noticed that they were from you and added your e-mail address to
the accept list. I'll swear that marked the Accept radiobutton for the
specific messages too, but it seems I failed to do that.

I'm very sorry about this mistake. Please accept my apologies, Karl.

BTW, isn't it possible to setup a spam filter that automatically
discards the most obvious occurrences? In the first week as moderator, I
received 1800 notifications about pending approvals, with perhaps 98%
of them spam.

-- 
Óscar

Re: Unable to close a bug in the tracker.

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

[snip]

> Trac is pretty, but I don't know how good it is at accepting email for
> comments, or even if it has an email control interface.

It has:

http://trac-hacks.org/wiki/MailToTracPlugin

[snip]

-- 
Óscar

Re: Unable to close a bug in the tracker.

[Stephen J. Turnbull]

Miles Bader writes:
 > Karl Fogel <kfogel@red-bean.com> writes:
 > > For the love of Cthulhu, why are we using this monstrosity when there
 > > are so many other good trackers out there?
 > 
 > Hm, is that really true?  It seems more like there are so many other
 > _bad_ trackers out there.

Let's not focus on "good vs. bad", let's focus on "debbugs vs.
something better".

 > The ones that do email well, screw up the web interface (or don't have
 > one).  The ones that do the web well screw up the email interface (or
 > don't have one).  Some screw both up.  Blah blah...

In that case, my advice is to choose one that does the web interface
well, and invest in some Elisp to manipulate it without touching the
mouse to approximate an email-based workflow.

Specifically, I chose Roundup for our bug tracker because it offered a
fighting chance of getting both the web interface and the email
interface tolerable.  Result: The email interface accepts mail, and
produces notifications to those on the nosy list, but nobody uses it
for control, and really no improvements have been installed to the
email interface in over 18 months because nobody needs them.  There
have been over 25 bugs against the web interface closed, and there are
still about 50 open.  Users care about the web interface.

That's what Karl said, of course, but maybe an opinion from the
viewpoint of a tracker maintainer would be of interest.

My opinions of the trackers I've reviewed.  Note that (except for
Roundup, which I use daily) these comments are 18-24 months old.  Most
of these products are quite mature, though.

Roundup has been sufficient for our needs.  I've had complaints that
it is "not Bugzilla", but nobody has gone to the extent of suggesting
that we should change, or refuses to use it.  Python has a much
improved version you could grab.  It has an excellent facility for
generating and saving queries so you can generate the reports you
need.

The LaunchPad tracker was not available when I set up our tracker, so
I never reviewed it carefully.  As a user, it is the least usable of
the major tracker products I've used (SourceForge, Bugzilla, RT, and
Trac).  There are lots of annoying project-related hoops to jump
through to get to the point where you can actually do something with
your bug report, and the documentation has that peculiar Canonical
odor of James Joyce writing to an audience he expects to consist
entirely of total n00bs.

RT was clunky and (for my needs) clearly dominated by Roundup.  Some
people love it, though.

Trac is pretty, but I don't know how good it is at accepting email for
comments, or even if it has an email control interface.  It also has
an obnoxious query interface.

Bugzilla: IMHO hard to go wrong by choosing Bugzilla, but I don't do
Perl.  There have been several Bugzilla variants with excellent email
support, but none were published at that time.  (Novell had one, for
example.)

SourceForge: not bad, if you can handle the various BS that
SourceForge bureaucracy imposes.  IIRC, it did handle email fairly
well according to its docs, but I never tried it.

bug spam [was Re: Unable to close a bug in the tracker.]

[Glenn Morris]

Óscar Fuentes wrote:

> BTW, isn't it possible to setup a spam filter that automatically
> discards the most obvious occurrences? 

The mails are already pre-processed by spamassassin before they get to
the moderators. The stuff that gets through has a low spam score
(check the headers). Maybe the spamassassin setup needs tuning, I
wouldn't know how.

There certainly is a lot of spam, as a legacy of debbugs refusal to
obscure email addresses published on the web. Almost all of the spam
comes in to emacsbugs.donarmstrong.com addresses. If it's ever
possible to drop that, there should be much less spam.

Re: Unable to close a bug in the tracker.

[Miles Bader]

Karl Fogel <kfogel@red-bean.com> writes:
> I mentioned Launchpad only because it's one of the few that offer both
> web and email UI (and does both well, IMHO), and therefore is a
> proof-by-existence that it doesn't have to be this way.

I admit, I tend to instinctively dismiss anything from canonical, and
indeed launchpad in particular (because of its proprietary past, and the
vague "all-consuming-bloat-master" feel one gets from using it on the
web).  Perhaps it's better than I assumed.

> We could use Bugzilla and still come out ahead.

I vaguely thought we were talking about bugzilla at some point, I dunno
what happened to that.  From that discussion, I seem to recall that it's
gained some email control/discussion features (the lack of which has
been a blocker for bugzilla traditionally), and seems to have slowly
been losing some of its "confusing mess" reputation.

[I think allowing email _replies_ in bug comments is pretty important --
there's absolutely nothing more annoying than getting email
"notification" of a discussion on a bug, and not being able to reply in
email... web interfaces are generally pretty good for clicking buttons
or searching, but not for having discussions.]

-Miles

-- 
Bride, n. A woman with a fine prospect of happiness behind her.

Re: Unable to close a bug in the tracker.

[Glenn Morris]

We just got this system set up on our own server less than a month
ago, after over a year of waiting, and after investing a lot of time
and effort in it. I don't think starting a discussion now about
changing it for something else is likely to result in much, to be
honest.

Re: bug spam

[Stefan Monnier]

>> BTW, isn't it possible to setup a spam filter that automatically
>> discards the most obvious occurrences? 
> The mails are already pre-processed by spamassassin before they get to
> the moderators. The stuff that gets through has a low spam score
> (check the headers). Maybe the spamassassin setup needs tuning, I
> wouldn't know how.
> There certainly is a lot of spam, as a legacy of debbugs refusal to
> obscure email addresses published on the web. Almost all of the spam
> comes in to emacsbugs.donarmstrong.com addresses. If it's ever
> possible to drop that, there should be much less spam.

I really really wish we could use gnu.org's "listhelper" to do
the moderation.


        Stefan

Re: Unable to close a bug in the tracker.

[Stefan Monnier]

> Now I'm going to rant.

FWIW, I'm not thrilled about Debbugs.
Its web interface obviously sucks and that's a problem.

It's email interface is also far from perfect.  One of the problems for
me is that it doesn't automatically thread bugs (if a reply to a bug is
sent without a "in-reply-to" or "references" header, as is sadly common,
Debbugs could add such a "references" header so all the messages are
automatically threaded in the MUA).

But overall, the email interface works well for us.  But clearly, we
want our users to help us maintain the bugs database and for that we
need a better web interface.

Still, the need for good email interface is a prerequisite for us.


        Stefan

Re: bug spam

[Glenn Morris]

Stefan Monnier wrote:

> I really really wish we could use gnu.org's "listhelper" to do
> the moderation.

Why can't we?

But IIUC, that just runs SpamAssassin to discard obvious spam via
automatic replies to Mailman moderation messages, so unless they have
a much better SpamAssassin setup than we do, I can't see that it will
help much.

Re: Unable to close a bug in the tracker.

[Glenn Morris]

Stefan Monnier wrote:

> Its web interface obviously sucks and that's a problem.

I see there is a long-term project to improve it:

http://wiki.debian.org/SummerOfCode2007/DebbugsWebUI

> One of the problems for me is that it doesn't automatically thread
> bugs (if a reply to a bug is sent without a "in-reply-to" or
> "references" header, as is sadly common, Debbugs could add such a
> "references" header so all the messages are automatically threaded
> in the MUA).

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485697

At least it isn't tagged "wontfix"! :)

Re: bug spam

[Yavor Doganov]

Glenn Morris wrote:
> Stefan Monnier wrote:
> > I really really wish we could use gnu.org's "listhelper" to do
> > the moderation.
> 
> But IIUC, that just runs SpamAssassin to discard obvious spam via
> automatic replies to Mailman moderation messages, so unless they have
> a much better SpamAssassin setup than we do, I can't see that it will
> help much.

No, there are people behind listhelper (Karl Berry, Bob Proulx, ...)
so there's a human element too.  (I never moderate my gnu.org lists;
the listhelper folks are just great.)

bug threading [was Re: Unable to close a bug in the tracker]

[Glenn Morris]

>> One of the problems for me is that it doesn't automatically thread
>> bugs (if a reply to a bug is sent without a "in-reply-to" or
>> "references" header, as is sadly common, Debbugs could add such a
>> "references" header so all the messages are automatically threaded
>> in the MUA).

I changed it so that messages without in-reply-to or references
headers get such headers pointing to the original bug report. I hope
this is an improvement. For technical reasons, it's easier to do this
than to point to the most recent message for any given bug number. In
the absence of a real in-reply-to, there's no way to tell which is
more likely to be correct anyway.

Please file bugs against debbugs.gnu.org for things you want changing;
this was the first time I had heard the above complaint.

Re: Unable to close a bug in the tracker.

[Deniz Dogan]

2010/1/14 Karl Fogel <kfogel@red-bean.com>:
> [snip]

I agree with virtually everything you said.

What _really_ bothers me about this bug tracking system (and I guess
I'm going out on a limb here) is that _some_ people are so stuck on
reading/adding/commenting on bugs using e-mail that A LOT of other
potential contributors to Emacs get sort of left out. It is NOT an
easy task to add a ticket to the bug tracker today (with all the tags
and what-not that needs to be right). It is NOT an easy thing to
change the meta-data of a bug either. "Commenting" on a ticket is
nearly as difficult.

Therefore, in my opinion, given the variety of bug tracking systems
that exist today, it was a huge mistake to make the e-mailing facility
the primary criteria even though it _is_ nice to be able to keep "M-x
report-emacs-bug" as simplistic as it is today. I understand that some
people, *cough*, don't use a web browser, but guess what, 99.999
percent of all Internet users today do use one. So don't leave them
out!

-- 
Deniz Dogan

Re: Unable to close a bug in the tracker.

[Andreas Schwab]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Bugzilla: IMHO hard to go wrong by choosing Bugzilla, but I don't do
> Perl.  There have been several Bugzilla variants with excellent email
> support, but none were published at that time.  (Novell had one, for
> example.)

Sourceware and GCC bugzilla accept comments by mail, but the rest is
web-only.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Unable to close a bug in the tracker.

[Xavier Maillard]

Hi,

   Karl Fogel <kfogel@red-bean.com> writes:
   > I mentioned Launchpad only because it's one of the few that offer both
   > web and email UI (and does both well, IMHO), and therefore is a
   > proof-by-existence that it doesn't have to be this way.

   I admit, I tend to instinctively dismiss anything from canonical, and
   indeed launchpad in particular (because of its proprietary past, and the
   vague "all-consuming-bloat-master" feel one gets from using it on the
   web).  Perhaps it's better than I assumed.

   > We could use Bugzilla and still come out ahead.

   I vaguely thought we were talking about bugzilla at some point, I dunno
   what happened to that.  From that discussion, I seem to recall that it's
   gained some email control/discussion features (the lack of which has
   been a blocker for bugzilla traditionally), and seems to have slowly
   been losing some of its "confusing mess" reputation.

   [I think allowing email _replies_ in bug comments is pretty important --
   there's absolutely nothing more annoying than getting email
   "notification" of a discussion on a bug, and not being able to reply in
   email... web interfaces are generally pretty good for clicking buttons
   or searching, but not for having discussions.]

This was one of the reason I proposed debbugs as a potential
candidate. THe main concern was a bug tracker usable my e-mail
and debbugs came to my mind.

Nobody imposed anything and choice was done after a long period
of experiment and many hours have been invested in "porting" what
Debian offered to something close to people needs. That's sad
people are desperately wanting to change this after all these
efforts.

If there are things to enhance, maybe we could try to see how to
do them and send them back upstream.


	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: Unable to close a bug in the tracker.

[Karl Fogel]

Glenn Morris <rgm@gnu.org> writes:
>Karl Fogel wrote:
>> I never have to read the documentation for other bug trackers I use,
>> because it's obvious how to use them.  If that doesn't seem like a major
>> win to you, I'm not sure what else to say... :-).
>
>I think it may be a cultural difference. Emacs bugs have always been
>reported and discussed by email. All the tracker really does is hook
>that up to a database so that things don't get forgotten about.

It is a cultural difference, sure.  But I'm claiming one of these
cultures is now dominant, so expecting developers to learn this other
culture is unrealistic.  Yes, *some* existing developers have learned
these ropes.  But the bug tracker is off-putting to *most* developers,
and (I'd bet) to the vast majority of potential new developers.

>All the submitter has to do is use M-x report-emacs-bug. This
>initiates an email exchange with the developers. The submitter doesn't
>need to know any of the details about the tracker. Only the developers
>are really expected to close and tag things (though if others want to,
>that's fine). It does require a bit of an investment to figure out how
>it works.

I agree that M-x report-emacs-bug should work, but that's independent of
using an email interface (in fact, due to unreliable spam filtering,
Emacs has no way of confirming right now whether it worked or not).

>I think developers are expected to subscribe to bug-gnu-emacs and keep
>an eye out for bugs that are relevant to them.

An interface that essentially requires developers to subscribe to Yet
Another Mailing List is a lose.

>Browsing bugs on the web and clicking on them to add comments isn't
>really what it was designed for.

Can't disagree with that :-).

>I'm certainly not debbugs #1 fan, but now that we've finally been able
>to tweak it a bit, I'm fairly happy with it.

I'm sure a few people, for whom the investment is worthwhile, are happy
with it.  I'm also (fairly) sure it's a productivity drain on the
majority of developers, since the majority of developers are not in a
position where that investment is worthwhile.  Imagine if every free
software project you worked on had a similar tool-learning cost, and all
the tools were different (as debbugs is different from virtually every
other tracker).  How scalable would that be?

If I had time, I'd do a survey of current Emacs package maintainers and
ask them if they monitor the bug tracker for bug reports about their
packages, by what method if so, and if they're happy with it.  But I
don't, because I'm too busy continuing to rant, I guess.

Re: Unable to close a bug in the tracker.

[Karl Fogel]

Glenn Morris <rgm@gnu.org> writes:
>Stefan Monnier wrote:
>> Its web interface obviously sucks and that's a problem.
>
>I see there is a long-term project to improve it:
>
>http://wiki.debian.org/SummerOfCode2007/DebbugsWebUI

This could be a win.

Do we have general agreement here that our bug tracker would be better
if it *did* have a web UI that allowed commenting and state-changing?
I.e., the lack of these features is not considered a feature, right?

Getting full bug database dump?

[Karl Fogel]

I asked this earlier in another thread, but it should really be a
separate request:

I'd like to get a full dump of our current debbugs database, to do some
quantitative analysis that I think might be useful for us.  As long as
it's in some parseable format, I can work with it.

Savannah admins don't maintain debbugs, right?  Does anyone know the
right place to ask for such data?

Thank you,
-Karl

Re: Getting full bug database dump?

[Chong Yidong]

Karl Fogel <kfogel@red-bean.com> writes:

> I asked this earlier in another thread, but it should really be a
> separate request:
>
> I'd like to get a full dump of our current debbugs database, to do some
> quantitative analysis that I think might be useful for us.  As long as
> it's in some parseable format, I can work with it.
>
> Savannah admins don't maintain debbugs, right?  Does anyone know the
> right place to ask for such data?

Go to fencepost, there's a copy of the database in ~cyd/debbugs.

Re: Unable to close a bug in the tracker.

[Chong Yidong]

Karl Fogel <kfogel@red-bean.com> writes:

> Do we have general agreement here that our bug tracker would be better
> if it *did* have a web UI that allowed commenting and state-changing?
> I.e., the lack of these features is not considered a feature, right?

It's probably not difficult to allow commenting from the web.  On the
bug pages, we can just insert a "mailto" link after each comment, with
the appropriate address and subject set up.

I'm a leery of getting us a full-fledged user-registration+web-forms
type solution.  We currently have a well-defined pathway for bug
information, which works pretty well (e.g. it catches spam mostly
correctly), and it would be nice not to deviate too much from it.

Re: Unable to close a bug in the tracker.

[Karl Fogel]

Chong Yidong <cyd@stupidchicken.com> writes:
>Karl Fogel <kfogel@red-bean.com> writes:
>> Do we have general agreement here that our bug tracker would be better
>> if it *did* have a web UI that allowed commenting and state-changing?
>> I.e., the lack of these features is not considered a feature, right?
>
>It's probably not difficult to allow commenting from the web.  On the
>bug pages, we can just insert a "mailto" link after each comment, with
>the appropriate address and subject set up.

Web UIs have a reliable network connection between the user and the
system, such that when the user completes an action, they can see for
certain it has been done.  Email cannot achieve that reliability, not
even in principle, and clearly not in practice.

>I'm a leery of getting us a full-fledged user-registration+web-forms
>type solution.  We currently have a well-defined pathway for bug
>information, which works pretty well (e.g. it catches spam mostly
>correctly), and it would be nice not to deviate too much from it.

Unless we've gone through all our bounce logs to see the rate at which
legitimate mails are blocked, we have no idea how well this system is
working.

-K

Re: Getting full bug database dump?

[Michael Albinus]

Karl Fogel <kfogel@red-bean.com> writes:

> Savannah admins don't maintain debbugs, right?  Does anyone know the
> right place to ask for such data?

Debbugs has a SOAP interface. Via this, you can retrieve bug data in XML
format.

A while ago, I've started to write a package xesam-debbugs.el. It ask
interactively for a filter of the bugs, retrieves them via the SOAP
interface, and displays them in a buffer. Everything asynchronously,
Emacs is not blocked.

The package is unfinished. I lost interested when I found out, that the
SOAP interface of debbugs does not support sorting (which is
inconvenient for a larger number of bugs returned).

However, it might be worth to continue the work?

> Thank you,
> -Karl

Best regards, Michael.

Re: bug spam

[Stefan Monnier]

> Why can't we?

Don't know that we can't.  I just don't know enough about how it works,
but I presumed that it's only setup to work for mailing lists @gnu.org.

An "easy" solution would be to add yet more forwarding hoops:

gnu-emacs-bug@gnu.org and *@debbugs.gnu.org would first be sent
over to emacs-debbugs-internal@gnu.org where we use GNU's listhelper
moderation and that list would have a single subscriber which is the real
"submit@debbugs.gnu.org" (which later on re-forwards to the subscribers
of gnu-emacs-bug@gnu.org.

> But IIUC, that just runs SpamAssassin to discard obvious spam via
> automatic replies to Mailman moderation messages,

That sounds backward: it would make a lot more sense (efficiencywise and
codingwise) to pass the emails through spamassassin before handing them
over to Mailman.

But the main point is that it's not just SpamAssassin: it uses a set of
human moderator-volunteers, and they get to share acceptance/rejection
rules across all lists.

The current debbugs moderation is pretty taxing in human time, because
of the enormous amount of spam that it gets.


        Stefan

Re: bug threading

[Stefan Monnier]

> I changed it so that messages without in-reply-to or references
> headers get such headers pointing to the original bug report. I hope
> this is an improvement. For technical reasons, it's easier to do this
> than to point to the most recent message for any given bug number. In
> the absence of a real in-reply-to, there's no way to tell which is
> more likely to be correct anyway.

You rock!


        Stefan

Re: Getting full bug database dump?

[Karl Fogel]

Michael Albinus <michael.albinus@gmx.de> writes:
>Debbugs has a SOAP interface. Via this, you can retrieve bug data in XML
>format.

Ah, thanks!  Yidong already made a dump, which I'm fetching (once my ssh
to fencepost is working), so I'll just make a note of the SOAP interface.

>A while ago, I've started to write a package xesam-debbugs.el. It ask
>interactively for a filter of the bugs, retrieves them via the SOAP
>interface, and displays them in a buffer. Everything asynchronously,
>Emacs is not blocked.
>
>The package is unfinished. I lost interested when I found out, that the
>SOAP interface of debbugs does not support sorting (which is
>inconvenient for a larger number of bugs returned).
>
>However, it might be worth to continue the work?

Hmm.  I can see how it would be useful, but if it would still be
one-way, I'm not it would be worth it... If it integrated with
message-mode, to make it two-way, that would be something.

Re: Unable to close a bug in the tracker.

[Stefan Monnier]

>> I think it may be a cultural difference. Emacs bugs have always been
>> reported and discussed by email. All the tracker really does is hook
>> that up to a database so that things don't get forgotten about.

> It is a cultural difference, sure.  But I'm claiming one of these
> cultures is now dominant, so expecting developers to learn this other
> culture is unrealistic.  Yes, *some* existing developers have learned
> these ropes.  But the bug tracker is off-putting to *most* developers,
> and (I'd bet) to the vast majority of potential new developers.

Kalr, please look at it from the other side: not that long ago, all the
bug handling was done on a mailing-list and nothing else.  That means
bug-lossage-galore and the only "web-interface" was the email archive.

The current web UI is clearly not as good as we'd like it to be, but
compared to what it was before Debbugs, there's no question that
it's improved.  Given the rate of evolution of Emacs development
practice, I think we're doing fairly well.  There's hope that within
a year or two, the web UI will be usable.

Personally, I'd be even more interested in a good debbugs-mode.
And that would be useful for all Emacs users, rather than just
for developpers.


        Stefan

Re: Unable to close a bug in the tracker.

[Karl Fogel]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>Karl, please look at it from the other side: not that long ago, all the
>bug handling was done on a mailing-list and nothing else.  That means
>bug-lossage-galore and the only "web-interface" was the email archive.
>
>The current web UI is clearly not as good as we'd like it to be, but
>compared to what it was before Debbugs, there's no question that
>it's improved.  Given the rate of evolution of Emacs development
>practice, I think we're doing fairly well.  There's hope that within
>a year or two, the web UI will be usable.

I completely understand the other side.  But Emacs is a project with a
very large, disparate group of developers, few of whom do it anything
close to full time.  So optimizing the bug tracker for the small
percentage of people who will become expert enough to be happy with it
seems like a mistake, unless the increase in the minority's efficiency
is *so* great as to outweigh the decrease in the majority's efficiency.
I strongly doubt that to be the case.

Again, I'm not opposed to having an email interface.  But a bug tracker
with *no reliable way to know that an operation has completed*?  That's
pretty basic.  If I wanted gambling I'd go to Vegas.

>Personally, I'd be even more interested in a good debbugs-mode.
>And that would be useful for all Emacs users, rather than just
>for developpers.

Emacs interfaces to bug trackers would be great.  That's not specific to
debbugs or to email-based interfaces, of course.

-Karl

Re: Getting full bug database dump?

[Michael Albinus]

Karl Fogel <kfogel@red-bean.com> writes:

> Hmm.  I can see how it would be useful, but if it would still be
> one-way, I'm not it would be worth it... If it integrated with
> message-mode, to make it two-way, that would be something.

That was on my todo list. One could imagine a debbugs-mode with some
basic features the Web UI offers. Useful not only for Emacs.

OTOH, there is the Debian debian-el package, which also offers
debbugs.el. I haven't tried it yet.

Best regards, Michael.

Re: Getting full bug database dump?

[Chong Yidong]

Michael Albinus <michael.albinus@gmx.de> writes:

>> Hmm.  I can see how it would be useful, but if it would still be
>> one-way, I'm not it would be worth it... If it integrated with
>> message-mode, to make it two-way, that would be something.
>
> That was on my todo list. One could imagine a debbugs-mode with some
> basic features the Web UI offers. Useful not only for Emacs.

It would also be nice if the debbugs package allowed browsing bug
reports as a Gnus feed.  (Also, I want a pony.)

Re: Getting full bug database dump?

[Michael Albinus]

Chong Yidong <cyd@stupidchicken.com> writes:

> It would also be nice if the debbugs package allowed browsing bug
> reports as a Gnus feed. 

Nice idea. I will think about.

> (Also, I want a pony.)

Don't expect it tomorrow. Christmas is over.

Best regards, Michael.

Re: Unable to close a bug in the tracker.

[Deniz Dogan]

2010/1/14 Karl Fogel <kfogel@red-bean.com>:
> Emacs interfaces to bug trackers would be great.  That's not specific to
> debbugs or to email-based interfaces, of course.

Something similar to this was discussed in the question session after
the Google Tech Talk about org-mode[1], about 43:45 seconds into the
video. The video unfortunately requires Flash to be viewed. Carsten
Dominik mentions that there are "plans" to implement
importing/exporting of wiki pages to/from org-mode and that it should
be fairly simple to implement.

So _if_ someone decides to write a wiki platform which can be used for
bug tracking, or if one already exists, I think the org-mode idea
would be a good candidate for contributing to it using nothing but
Emacs.

[1] http://orgmode.org/GoogleTech.html

-- 
Deniz Dogan

Re: Getting full bug database dump?

[Ted Zlatanov]

On Thu, 14 Jan 2010 11:20:37 -0500 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> Michael Albinus <michael.albinus@gmx.de> writes:
>>> Hmm.  I can see how it would be useful, but if it would still be
>>> one-way, I'm not it would be worth it... If it integrated with
>>> message-mode, to make it two-way, that would be something.
>> 
>> That was on my todo list. One could imagine a debbugs-mode with some
>> basic features the Web UI offers. Useful not only for Emacs.

CY> It would also be nice if the debbugs package allowed browsing bug
CY> reports as a Gnus feed.  (Also, I want a pony.)

Do you mean a RSS feed?  Or do you mean a full Gnus backend?  The latter
has potential as it would allow posting.  The metadata could be in the
headers.

Ted

Re: Unable to close a bug in the tracker.

[Glenn Morris]

Chong Yidong wrote:

> It's probably not difficult to allow commenting from the web.  On the
> bug pages, we can just insert a "mailto" link after each comment, with
> the appropriate address and subject set up.

The default set up does something like that, but as I say I removed it
in an anti-spam effort.

Re: Unable to close a bug in the tracker.

[Glenn Morris]

Deniz Dogan wrote:

> It is NOT an easy task to add a ticket to the bug tracker today
> (with all the tags and what-not that needs to be right).

You do not need to worry about tags and what-not, at all.

To report a new bug, use M-x report-emacs-bug. That's it.

> It is NOT an easy thing to change the meta-data of a bug either.

No, but I would say most people don't need to worry about it.
If you want to, you'll have to read up a little, yes.

> "Commenting" on a ticket is nearly as difficult.

To comment on 123, send a mail to 123@debbugs. That's it.
Or to bug-gnu-emacs, with "Bug#123" in the subject.

Re: bug spam

[Glenn Morris]

Stefan Monnier wrote:

> That sounds backward: it would make a lot more sense (efficiencywise and
> codingwise) to pass the emails through spamassassin before handing them
> over to Mailman.

Yes, it would. But the point of the listhelper system is for places
where you can't do that:

http://www.nongnu.org/listhelper/
from README:

    The best place to put anti-spam controls is at the earliest point
    where spam can enter the system. Unfortunately I couldn't affect
    changes to the upstream mail filtering.

> The current debbugs moderation is pretty taxing in human time, because
> of the enormous amount of spam that it gets.

I don't think it's unmanageable.

Re: bug spam

[Glenn Morris]

Glenn Morris wrote (on Thu, 14 Jan 2010 at 12:14 -0500):

> > The current debbugs moderation is pretty taxing in human time, because
> > of the enormous amount of spam that it gets.
> 
> I don't think it's unmanageable.

PS. How about auto-discarding mail sent to

[0-9]-(close|done)@emacsbugs ?

(Perhaps I'm fixated on this idea.)

Re: Getting full bug database dump?

[Dan Nicolaescu]

Karl Fogel <kfogel@red-bean.com> writes:

  > I asked this earlier in another thread, but it should really be a
  > separate request:
  > 
  > I'd like to get a full dump of our current debbugs database, to do some
  > quantitative analysis that I think might be useful for us.  As long as
  > it's in some parseable format, I can work with it.

If you have the time, there's one more thing this would be useful for:
find all the bugs that have patches in them (just search for the diff
headers), and make sure they are tagged with "patch". 

Re: Getting full bug database dump?

[Stefan Monnier]

>> The package is unfinished. I lost interested when I found out, that the
>> SOAP interface of debbugs does not support sorting (which is
>> inconvenient for a larger number of bugs returned).
>> However, it might be worth to continue the work?

> Hmm.  I can see how it would be useful, but if it would still be
> one-way, I'm not it would be worth it... If it integrated with
> message-mode, to make it two-way, that would be something.

Clearly, we'd want to make it bodirectional.  Not just via message-mode,
but also by extending the SOAP interface so we can send commands (the
advantage being, as you pointed out, that we can get "immediate"
confirmation that the command was accepted).


        Stefan

Re: Getting full bug database dump?

[Karl Fogel]

Dan Nicolaescu <dann@ics.uci.edu> writes:
>Karl Fogel <kfogel@red-bean.com> writes:
>  > I asked this earlier in another thread, but it should really be a
>  > separate request:
>  > 
>  > I'd like to get a full dump of our current debbugs database, to do some
>  > quantitative analysis that I think might be useful for us.  As long as
>  > it's in some parseable format, I can work with it.
>
>If you have the time, there's one more thing this would be useful for:
>find all the bugs that have patches in them (just search for the diff
>headers), and make sure they are tagged with "patch". 

I may be able to produce that information, along with the other stuff
I'm looking at, sure.

Re: Unable to close a bug in the tracker.

[Stefan Monnier]

> I completely understand the other side.  But Emacs is a project with a
> very large, disparate group of developers, few of whom do it anything
> close to full time.  So optimizing the bug tracker for the small
> percentage of people who will become expert enough to be happy with it
> seems like a mistake, unless the increase in the minority's efficiency
> is *so* great as to outweigh the decrease in the majority's efficiency.
> I strongly doubt that to be the case.

My point was that it's *not* optimized for the minority "heavy
maintainer": it's just a point in time along the path from "mailing-list
only" to something more friendly to end-users (and other contributors).


        Stefan

Re: bug spam

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> PS. How about auto-discarding mail sent to
>
> [0-9]-(close|done)@emacsbugs ?
>
> (Perhaps I'm fixated on this idea.)

This has the problem that if someone might look up an old bug on the web
interface, and sends an email in reply to the address recorded on that
bug.  Or, the bug reporter might be responding to an email from one of
us, with "CC: ####@emacsbugs", after a long delay.  Such emails would be
lost.

Re: bug spam

[Glenn Morris]

Stefan Monnier wrote:

> Don't know that we can't.  I just don't know enough about how it works,
> but I presumed that it's only setup to work for mailing lists @gnu.org.

https://savannah.gnu.org/maintenance/ListHelperAntiSpam

    Actually, the listhelper system is not tied to gnu.org in any way.
    A few people are using it for handling non-GNU mailman lists as
    well. If you'd like to do that, email us.

> But the main point is that it's not just SpamAssassin: it uses a set of
> human moderator-volunteers, and they get to share acceptance/rejection
> rules across all lists.

It feels like passing the buck to me. "We left all our email addresses
published on the web for over a year, and now we get too much spam.
Please moderate it for us."

Re: bug spam

[Stefan Monnier]

> PS. How about auto-discarding mail sent to
> [0-9]-(close|done)@emacsbugs ?

Sounds fine, tho I don't think it's a large enough fraction to make
a significant difference.


        Stefan

Re: Unable to close a bug in the tracker.

[Deniz Dogan]

2010/1/14 Glenn Morris <rgm@gnu.org>:
> Deniz Dogan wrote:
>
>> It is NOT an easy task to add a ticket to the bug tracker today
>> (with all the tags and what-not that needs to be right).
>
> You do not need to worry about tags and what-not, at all.

I've been told numerous times to add tags and what-not to patches I've
submitted to the bug tracker. (Maybe I should have made that clear.)

> To report a new bug, use M-x report-emacs-bug. That's it.

But that doesn't apply to patches.

>> It is NOT an easy thing to change the meta-data of a bug either.
>
> No, but I would say most people don't need to worry about it.
> If you want to, you'll have to read up a little, yes.

You have to worry about it when you forgot to add tags and such in the
first place.

>> "Commenting" on a ticket is nearly as difficult.
>
> To comment on 123, send a mail to 123@debbugs. That's it.
> Or to bug-gnu-emacs, with "Bug#123" in the subject.
>

I stand corrected.

-- 
Deniz Dogan

Re: Unable to close a bug in the tracker.

[Xavier Maillard]

   Glenn Morris <rgm@gnu.org> writes:
   >Stefan Monnier wrote:
   >> Its web interface obviously sucks and that's a problem.
   >
   >I see there is a long-term project to improve it:
   >
   >http://wiki.debian.org/SummerOfCode2007/DebbugsWebUI

   This could be a win.

   Do we have general agreement here that our bug tracker would be better
   if it *did* have a web UI that allowed commenting and state-changing?
   I.e., the lack of these features is not considered a feature, right?

I do (even if I never use it.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: Unable to close a bug in the tracker.

[Stefan Monnier]

>> To report a new bug, use M-x report-emacs-bug. That's it.
> But that doesn't apply to patches.

It does (unless it's a patch for a pre-existing bug).


        Stefan

Emacs interface to debbugs (was: Getting full bug database dump?)

[Reiner Steib]

On Thu, Jan 14 2010, Ted Zlatanov wrote:

> On Thu, 14 Jan 2010 11:20:37 -0500 Chong Yidong <cyd@stupidchicken.com> wrote: 
>
> CY> Michael Albinus <michael.albinus@gmx.de> writes:
>>>> Hmm.  I can see how it would be useful, but if it would still be
>>>> one-way, I'm not it would be worth it... If it integrated with
>>>> message-mode, to make it two-way, that would be something.
>>> 
>>> That was on my todo list. One could imagine a debbugs-mode with some
>>> basic features the Web UI offers. Useful not only for Emacs.
>
> CY> It would also be nice if the debbugs package allowed browsing bug
> CY> reports as a Gnus feed.  (Also, I want a pony.)
>
> Do you mean a RSS feed?  Or do you mean a full Gnus backend?  The latter
> has potential as it would allow posting.  The metadata could be in the
> headers.

We already have `gnus-read-ephemeral-bug-group' for reading specific
bugs.  IMHO, what we need next is to adopt Peter S. Galbraith's
(Cc-ed) Debian Emacs package (debian-bug.el?) to Emacs' debbugs so
that we can do most of the things described in admin/notes/bugtracker
(tagging, closing, ...)  from Emacs (message-mode).

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Getting full bug database dump?

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Clearly, we'd want to make it bodirectional.  Not just via message-mode,
> but also by extending the SOAP interface so we can send commands (the
> advantage being, as you pointed out, that we can get "immediate"
> confirmation that the command was accepted).

1+.

A short overview of the existing SOAP interface can be found at
<http://wiki.debian.org/DebbugsSoapInterface>. We should contact Don
Armstrong, who is one of the maintainers.

Nevertheless, being able to view bugs inside Emacs might be useful
already as first step.

>         Stefan

Best regards, Michael.

Re: Emacs interface to debbugs

[Michael Albinus]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> We already have `gnus-read-ephemeral-bug-group' for reading specific
> bugs.

The advantage of the Debbugs SOAP interface is, that you can search over
the whole database. `gnus-read-ephemeral-bug-group' seems to be focused
on just one bug, you know the number.

> Bye, Reiner.

Best regards, Michael.

Re: Emacs interface to debbugs

[Ted Zlatanov]

On Thu, 14 Jan 2010 20:33:20 +0100 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> On Thu, Jan 14 2010, Ted Zlatanov wrote:
>> On Thu, 14 Jan 2010 11:20:37 -0500 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> It would also be nice if the debbugs package allowed browsing bug
CY> reports as a Gnus feed.  (Also, I want a pony.)
>> 
>> Do you mean a RSS feed?  Or do you mean a full Gnus backend?  The latter
>> has potential as it would allow posting.  The metadata could be in the
>> headers.

RS> We already have `gnus-read-ephemeral-bug-group' for reading specific
RS> bugs.  IMHO, what we need next is to adopt Peter S. Galbraith's
RS> (Cc-ed) Debian Emacs package (debian-bug.el?) to Emacs' debbugs so
RS> that we can do most of the things described in admin/notes/bugtracker
RS> (tagging, closing, ...)  from Emacs (message-mode).

IMHO it's easier to do these actions from the MUA (Gnus) than from the
lower level of message-mode.  I could be wrong, though, and see my
caveat below.

On Thu, 14 Jan 2010 21:35:27 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> The advantage of the Debbugs SOAP interface is, that you can search over
MA> the whole database. `gnus-read-ephemeral-bug-group' seems to be focused
MA> on just one bug, you know the number.

A full Gnus backend would, instead of creating an ephemeral group for
the bug, provide the usual facilities for listing, reading, and creating
articles that mirror bugs.  I think this is valuable.

OTOH not everyone wants to use Gnus, but everyone can use message-mode.
So this is useful to only some people--is it worth the effort to discuss
and develop it?

Ted

Re: Unable to close a bug in the tracker.

[Stephen J. Turnbull]

Stefan Monnier writes:

 > My point was that it's *not* optimized for the minority "heavy
 > maintainer": it's just a point in time along the path from "mailing-list
 > only" to something more friendly to end-users (and other contributors).

Unfortunately, given that somebody was paid to do the job and didn't
finish it, moving on from here will probably require switching
trackers.

Re: Unable to close a bug in the tracker.

[Stefan Monnier]

>> My point was that it's *not* optimized for the minority "heavy
>> maintainer": it's just a point in time along the path from "mailing-list
>> only" to something more friendly to end-users (and other contributors).
> Unfortunately, given that somebody was paid to do the job and didn't
> finish it, moving on from here will probably require switching
> trackers.

If that's what it takes, we'll do that.


        Stefan

Re: Unable to close a bug in the tracker.

[Glenn Morris]

Deniz Dogan wrote:

> I've been told numerous times to add tags and what-not to patches
> I've submitted to the bug tracker.

I hope that's not an impression I've given. If you want to tag patches
you send, or try and put things in a certain package, great, but it
makes very little difference to me, and I certainly don't see it as the
responsibility of the submitter to know anything about that stuff.

>> To report a new bug, use M-x report-emacs-bug. That's it.
>
> But that doesn't apply to patches.

Patches are welcome via that mechanism, or you can just send a mail to
bug-gnu-emacs@gnu. I think that's always been the documented method.

Re: bug spam

[Glenn Morris]

Stefan Monnier wrote:

>> PS. How about auto-discarding mail sent to
>> [0-9]-(close|done)@emacsbugs ?
>
> Sounds fine, tho I don't think it's a large enough fraction to make
> a significant difference.

Of 2160 moderation messages in the past week:

1951 were for mails sent to emacsbugs addresses  (90%)
466 were for mails sent to done|close@emacsbugs  (22%)

But it's probably a bad idea to think this way.

Re: Unable to close a bug in the tracker.

[Miles Bader]

Karl Fogel <kfogel@red-bean.com> writes:
> Emacs interfaces to bug trackers would be great.  That's not specific to
> debbugs or to email-based interfaces, of course.

... but to anyone thinking about it, remember that many people are
behind firewalls that only let through email and http connections...

-Miles

-- 
97% of everything is grunge

Re: Unable to close a bug in the tracker.

[Richard Stallman]

    What _really_ bothers me about this bug tracking system (and I guess
    I'm going out on a limb here) is that _some_ people are so stuck on
    reading/adding/commenting on bugs using e-mail that A LOT of other
    potential contributors to Emacs get sort of left out.

We decided not to leave ourselves out.

If you don't like the debbugs system as it is,
how about working on making it better?

Re: Unable to close a bug in the tracker.

[Deniz Dogan]

2010/1/15 Richard Stallman <rms@gnu.org>:
>    What _really_ bothers me about this bug tracking system (and I guess
>    I'm going out on a limb here) is that _some_ people are so stuck on
>    reading/adding/commenting on bugs using e-mail that A LOT of other
>    potential contributors to Emacs get sort of left out.
>
> We decided not to leave ourselves out.
>

By "we", do you mean the few that do not use a web browser today? I'm
sure the majority of all Emacs developers and/or contributors would
prefer to have a web interface instead of an e-mail interface if they
had to choose between only one of them.

-- 
Deniz Dogan

Re: Unable to close a bug in the tracker.

[Eli Zaretskii]

> From: Deniz Dogan <deniz.a.m.dogan@gmail.com>
> Date: Sat, 16 Jan 2010 05:02:28 +0100
> Cc: kfogel@red-bean.com, emacs-devel@gnu.org
> 
> 2010/1/15 Richard Stallman <rms@gnu.org>:
> >    What _really_ bothers me about this bug tracking system (and I guess
> >    I'm going out on a limb here) is that _some_ people are so stuck on
> >    reading/adding/commenting on bugs using e-mail that A LOT of other
> >    potential contributors to Emacs get sort of left out.
> >
> > We decided not to leave ourselves out.
> >
> 
> By "we", do you mean the few that do not use a web browser today? I'm
> sure the majority of all Emacs developers and/or contributors would
> prefer to have a web interface instead of an e-mail interface if they
> had to choose between only one of them.

Don't be sure without a poll.  The result might surprise you.

Re: Unable to close a bug in the tracker.

[Reiner Steib]

On Sat, Jan 16 2010, Eli Zaretskii wrote:

>> From: Deniz Dogan <deniz.a.m.dogan@gmail.com>
>> 2010/1/15 Richard Stallman <rms@gnu.org>:

[ about reading/adding/commenting on bugs using e-mail ]

>> > We decided not to leave ourselves out.
>> >
>> 
>> By "we", do you mean the few that do not use a web browser today? I'm
>> sure the majority of all Emacs developers and/or contributors would
>> prefer to have a web interface instead of an e-mail interface if they
>> had to choose between only one of them.
>
> Don't be sure without a poll.  The result might surprise you.

My guess is that the majority of Emacs developers wants an Emacs
interface, no matter if it interacts via SMTP or HTTP with the
database.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Unable to close a bug in the tracker.

[Óscar Fuentes]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

>>> By "we", do you mean the few that do not use a web browser today? I'm
>>> sure the majority of all Emacs developers and/or contributors would
>>> prefer to have a web interface instead of an e-mail interface if they
>>> had to choose between only one of them.
>>
>> Don't be sure without a poll.  The result might surprise you.
>
> My guess is that the majority of Emacs developers wants an Emacs
> interface, no matter if it interacts via SMTP or HTTP with the
> database.

Please note that not only the developers interact with the bug
tracker. A user could be interested in closing a bug he previously
reported, or add a commentary to other report. Finally, not everyone has
mail access from Emacs.

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

-- 
Óscar

Re: Unable to close a bug in the tracker.

[Xavier Maillard]

   2010/1/15 Richard Stallman <rms@gnu.org>:
   >    What _really_ bothers me about this bug tracking system (and I guess
   >    I'm going out on a limb here) is that _some_ people are so stuck on
   >    reading/adding/commenting on bugs using e-mail that A LOT of other
   >    potential contributors to Emacs get sort of left out.
   >
   > We decided not to leave ourselves out.
   >

   By "we", do you mean the few that do not use a web browser today? I'm
   sure the majority of all Emacs developers and/or contributors would
   prefer to have a web interface instead of an e-mail interface if they
   had to choose between only one of them.

I am not a core Emacs developers, not even a regular contributor
but I really do not see the benefit of an HTTP interface other
simple email exchanges. At the very least, an emacs mode would be
enough for me *but* web would not help here.

YMMV off course.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: Unable to close a bug in the tracker.

[Richard Stallman]

    By "we", do you mean the few that do not use a web browser today? 

We Emacs developers, who are used to discussing the work on Emacs by email.

Re: Unable to close a bug in the tracker.

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
> Please note that not only the developers interact with the bug
> tracker. A user could be interested in closing a bug he previously
> reported, or add a commentary to other report. Finally, not everyone has
> mail access from Emacs.
>
> The Version Control system must be tailored to developers. The bug
> tracker shall be accessible to users as well.

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

(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)

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...

-Miles

-- 
Custard, n. A vile concoction produced by a malevolent conspiracy of the hen,
the cow, and the cook.

Re: Unable to close a bug in the tracker.

[Stephen J. Turnbull]

Miles Bader writes:
 > Óscar Fuentes <ofv@wanadoo.es> 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.

Re: Unable to close a bug in the tracker.

[Stephen J. Turnbull]

Stephen J. Turnbull writes:

 >  > (2) How convenient a particular interface (web / emacs / generic email)
 >  >      is depends on the operation

 > Nope.  It varies by project

Oh yeah, I forgot one *very* important use case for (moderately
clueful users *and* developers) wanting a web interface rather than an
email interface: bug triage.  This is a service that
non-project-developer users successfully provide to many projects.

And don't mention Gnus.  For all practical purposes, Gnus *is* a web
interface (ie, you can access pretty much any Internet resource via
Gnus).  :-)

Re: Unable to close a bug in the tracker.

[Glenn Morris]

I have filed bugs 5418 and 5419. If anyone would like to help implement
these features, that would be great.

If anyone thinks an entirely new bug tracker is needed (I have no
interest in helping with this), I would suggest the following steps:

1) go back and read all the previous discussion about this, to make
sure you know what people actually said, what's been tried before,
what's important, how we got to where we are now, and to avoid
rehashing old arguments.

2) choose your alternative system. It should satisfy all the criteria
that have been stated before, do everything we want to do now, and
everything you want to do in the future.

3) set it up, import the existing bug database, and provide a test
setup that people can try out.

4) answer any questions people might have about the system, implement
any changes they ask for, document how it works.

5) wait for people to decide if they like it better than the current
system.


I would suggest making a new, more focused thread for any further
discussion.

Re: bug spam

[Glenn Morris]

Glenn Morris wrote:

> Of 2160 moderation messages in the past week:
>
> 1951 were for mails sent to emacsbugs addresses  (90%)
> 466 were for mails sent to done|close@emacsbugs  (22%)
>
> But it's probably a bad idea to think this way.

Somebody seems to have added a mailman auto-discard rule for

^[0-9]+.*@emacsbugs.donarmstrong.com

I wondered why there were suddenly so few moderation requests...

Re: bug spam

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> Somebody seems to have added a mailman auto-discard rule for
>
> ^[0-9]+.*@emacsbugs.donarmstrong.com
>
> I wondered why there were suddenly so few moderation requests...

It was not me.  I'm not sure we should add this filter, because it may
interfere with follow-ups to old bug reports.

Re: bug spam

[Glenn Morris]

Chong Yidong wrote:

>> Somebody seems to have added a mailman auto-discard rule for
>>
>> ^[0-9]+.*@emacsbugs.donarmstrong.com
>>
>> I wondered why there were suddenly so few moderation requests...
>
> It was not me.  I'm not sure we should add this filter, because it may
> interfere with follow-ups to old bug reports.

I agree with you. Such addresses were in use as recently as 3 days ago
(eg in bug#5042).

Re: bug spam

[Glenn Morris]

>>> Somebody seems to have added a mailman auto-discard rule for
>>>
>>> ^[0-9]+.*@emacsbugs.donarmstrong.com

Ack, this was just me being dumb: that's a sender filter, not a recipient
filter. Sorry for the noise.