Re: Bug trackers

Re: Bug trackers

[Don Armstrong]

I'm one of the current upstream developers for debbugs; Manoj pointed
me at this discussion in IRC earlier (CC if you want me to respond, or
obey M-F-T. ;-)).[0]

It wouldn't be too terribly difficult to set up an instance of debbugs
to allow testing to see if it will work for emacs development. I also
wouldn't mind making changes as required to make it fit in better with
the emacs development model[1] (as debbugs is rather Debian specific
now.)

The codebase is here in a bzr repository:
http://bugs.debian.org/debbugs-source/, the mainline branch is our
"distributable" branch, and the "debian" branch is the code that is
actually running on bugs.debian.org. If someone who wants to set it up
needs a hand configuring it, let me or debian-devel@lists.debian.org
know.[2]

Also, feel free to ask if you have questions about specific features
of Debbugs.


Don Armstrong

0: Hopefully I haven't hideously broken this thread; unfortunatly, the
lack of mboxes on the web archive makes that "interesting".

1: I don't really know how you all develop emacs, so I would need
significant input on what changes were needed.

2: I don't currently have a demo of it set up, though I have had one
running in the past.
-- 
Grimble left his mother in the food store and went to the launderette
and watched the clothes go round. It was a bit like colour television
only with less plot.
 -- Clement Freud _Grimble_

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Bug trackers

[Richard Stallman]

    It wouldn't be too terribly difficult to set up an instance of debbugs
    to allow testing to see if it will work for emacs development. I also
    wouldn't mind making changes as required to make it fit in better with
    the emacs development model[1] (as debbugs is rather Debian specific
    now.)

Thank you.  Please do that; it will be very useful for us.

I expect that any changes which make it more useful for us
will also make it more useful for other programs whose developers
talk a lot by email.

    1: I don't really know how you all develop emacs, so I would need
    significant input on what changes were needed.

I don't have a vocabulary to describe different "ways" to
develop a program, so I would not know how to answer.
Maybe someone else knows how to answer you more usefully.
But I think that if you subscribe to emacs-devel for a week
you'll more or less know the answer.

Re: Bug trackers

[Don Armstrong]

On Mon, 18 Feb 2008, Richard Stallman wrote:
>     It wouldn't be too terribly difficult to set up an instance of debbugs
>     to allow testing to see if it will work for emacs development. I also
>     wouldn't mind making changes as required to make it fit in better with
>     the emacs development model[1] (as debbugs is rather Debian specific
>     now.)
> 
> Thank you.  Please do that; it will be very useful for us.

I'll have a chance to finish setting it up in a day or so. [Made a
mistake, and my DNS ttl is too long for me to finish it now.]

> I expect that any changes which make it more useful for us will also
> make it more useful for other programs whose developers talk a lot
> by email.
>
>     1: I don't really know how you all develop emacs, so I would need
>     significant input on what changes were needed.
> 
> I don't have a vocabulary to describe different "ways" to develop a
> program, so I would not know how to answer. Maybe someone else knows
> how to answer you more usefully. But I think that if you subscribe
> to emacs-devel for a week you'll more or less know the answer.

The main issue is that it's set up right now for distributions, where
you have thousands of packages and developers all working on their own
separate little bits of the system and only release managers care
about everything together.

What I kind of imagine is that bits of emacs which are relatively
separate would end up with their own "package" and this mailing list
(or the people responsible?) would be primarily tasked with fixing and
resolving them. But that's just my uniformed idea from the start;
Manoj is probably the right person to recommend any changes needed,
since he knows more about emacs development than I do and has used
debbugs extensively.


Don Armstrong

-- 
"Because," Fee-5 explained patiently, "I was born in the fifth row.
Any fool would understand that, but against stupidity the very Gods
themselves contend in vain."
 -- Alfred Bester _The Computer Connection_ p19

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Bug trackers

[Richard Stallman]

    The main issue is that it's set up right now for distributions, where
    you have thousands of packages and developers all working on their own
    separate little bits of the system and only release managers care
    about everything together.

Yes, that is true.

    What I kind of imagine is that bits of emacs which are relatively
    separate would end up with their own "package" and this mailing list
    (or the people responsible?) would be primarily tasked with fixing and
    resolving them.

The issue here is to consider using a bug tracker.  To change the way
we package Emacs would be a completely different issue (and I don't
think we should do so).

What leads you to raise the question of packaging in relation to
using a bug tracker?

Re: Bug trackers

[Jason Rumney]

Richard Stallman wrote:
> The issue here is to consider using a bug tracker.  To change the way
> we package Emacs would be a completely different issue (and I don't
> think we should do so).
>   
We wouldn't necessarily need to package Emacs, just partition 
responsibility for the bug reports as if different parts of Emacs were 
separate projects.

It might be useful for major packages that are already separately 
developed, like tramp, c-mode and gnus.

Re: Bug trackers

[Karl Fogel]

Jason Rumney <jasonr@gnu.org> writes:
> Richard Stallman wrote:
>> The issue here is to consider using a bug tracker.  To change the way
>> we package Emacs would be a completely different issue (and I don't
>> think we should do so).
>>   
> We wouldn't necessarily need to package Emacs, just partition
> responsibility for the bug reports as if different parts of Emacs were
> separate projects.
>
> It might be useful for major packages that are already separately
> developed, like tramp, c-mode and gnus.

Folks, let's just try it and see how it works.

Discussing it in advance of trying it will not be productive, I think.

Re: Bug trackers

[Xavier Maillard]

Hi,

   It might be useful for major packages that are already separately 
   developed, like tramp, c-mode and gnus.

I like the idea but why not integrate the bug tracker with the
savannah platform which is hosting current GNU Emacs project ?
Are the savannah hackers aware of RMS request ?

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

Re: Bug trackers

[Richard Stallman]

    I like the idea but why not integrate the bug tracker with the
    savannah platform which is hosting current GNU Emacs project ?
    Are the savannah hackers aware of RMS request ?

One step at a time please.  Right now we are trying out a bug tracker
to see if it works for us.  It is too early to talk about integrating
it into Savannah.  We have too many issues to discuss now.
Please let this one wait until it is needed.

Re: Bug trackers

[Xavier Maillard]

       I like the idea but why not integrate the bug tracker with the
       savannah platform which is hosting current GNU Emacs project ?
       Are the savannah hackers aware of RMS request ?

   One step at a time please.  Right now we are trying out a bug tracker
   to see if it works for us.  It is too early to talk about integrating
   it into Savannah.  We have too many issues to discuss now.
   Please let this one wait until it is needed.

You are right but my aim when asking this was to know why savane
project did not offer such a bug tracker yet. Anyway, I agree and
as we say in France: ne mettons pas la charrue avant les boeufs.

Regards,

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

Re: Bug trackers

[Don Armstrong]

On Tue, 19 Feb 2008, Richard Stallman wrote:
>     What I kind of imagine is that bits of emacs which are relatively
>     separate would end up with their own "package" and this mailing list
>     (or the people responsible?) would be primarily tasked with fixing and
>     resolving them.
> 
> The issue here is to consider using a bug tracker.  To change the way
> we package Emacs would be a completely different issue (and I don't
> think we should do so).

Definetly; my point wasn't about changing the way emacs is developed
(if a bug tracker were to cause you to do that, it's probably the
wrong one to use).
 
> What leads you to raise the question of packaging in relation to
> using a bug tracker?

Debbugs currently is based on the assumption that every bug is
assigned to at least one package. In terms of a distribution, this
makes perfect sense, but it's different for applications. When you're
developing a single application like emacs, I'd imagine you'd separate
bugs into "components" or similar of the application, like "gtk
interface", "documentation", or "elisp" (as examples; you all'd come
up with better ones.)

That's really done just to help organize bugs, but is kind of
fundamental to debbug's internals.


Don Armstrong

-- 
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Bug trackers

[Richard Stallman]

    Debbugs currently is based on the assumption that every bug is
    assigned to at least one package. In terms of a distribution, this
    makes perfect sense, but it's different for applications. When you're
    developing a single application like emacs, I'd imagine you'd separate
    bugs into "components" or similar of the application, like "gtk
    interface", "documentation", or "elisp" (as examples; you all'd come
    up with better ones.)

Is it possible for all bugs to be initially assigned to "emacs"
and for maintainers to move them subsequently into other categories?

Re: Bug trackers

[Don Armstrong]

On Wed, 20 Feb 2008, Richard Stallman wrote:
>     Debbugs currently is based on the assumption that every bug is
>     assigned to at least one package. In terms of a distribution, this
>     makes perfect sense, but it's different for applications. When you're
>     developing a single application like emacs, I'd imagine you'd separate
>     bugs into "components" or similar of the application, like "gtk
>     interface", "documentation", or "elisp" (as examples; you all'd come
>     up with better ones.)
> 
> Is it possible for all bugs to be initially assigned to "emacs"
> and for maintainers to move them subsequently into other categories?

Yes, we can assign bugs to emacs if there isn't a valid package or
even if the submit mail wasn't able to be parsed.


Don Armstrong

-- 
I'd sign up in a hot second for any cellular company whose motto was:
"We're less horrible than a root canal with a cold chisel."
 -- Cory Doctorow

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Bug trackers

[Don Armstrong]

On Wed, 20 Feb 2008, Don Armstrong wrote:
> On Wed, 20 Feb 2008, Richard Stallman wrote:
> >     Debbugs currently is based on the assumption that every bug is
> >     assigned to at least one package. In terms of a distribution, this
> >     makes perfect sense, but it's different for applications. When you're
> >     developing a single application like emacs, I'd imagine you'd separate
> >     bugs into "components" or similar of the application, like "gtk
> >     interface", "documentation", or "elisp" (as examples; you all'd come
> >     up with better ones.)
> > 
> > Is it possible for all bugs to be initially assigned to "emacs"
> > and for maintainers to move them subsequently into other categories?
> 
> Yes, we can assign bugs to emacs if there isn't a valid package or
> even if the submit mail wasn't able to be parsed.

This is now the case for the debbugs testbed. [It required a new
feature to be added, so if it fails for some reason, please let me
know.]
 

Don Armstrong

-- 
If I had a letter, sealed it in a locked vault and hid the vault
somewhere in New York. Then told you to read the letter, thats not
security, thats obscurity. If I made a letter, sealed it in a vault,
gave you the blueprints of the vault, the combinations of 1000 other
vaults, access to the best lock smiths in the world, then told you to
read the letter, and you still can't, thats security.
 -- Bruce Schneier

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Bug trackers

[Stefan Monnier]

I started to play with the emacsbugs thingy (as Richard is stepping down
as maintainer and was basically doing the bug-tracking himself, I'm
eager to setup a "new" non-human bug-tracking system) and have some more
questions:

- I see that right now, the address emacsbugs@lists.donarmstrong.com is
  used only for the `emacs' package.  Would it be possible to use it as
  the default address for each and every package?

- how can I manage the email address used as the maintainer of
  a particular package?  I see I can change the owner of a bug, but
  I can't see how to manipulate the maintainer of a package.

- I see I can "create" a package as a side effect of reassigning a bug
  to some inexistent package.  What about deleting a package or merging
  it with another one?

- As Richard mentioned, we would like/need to forward all bug-reports
  sent to bug-gnu-emacs@gnu.org and emacs-pretest-bug@gnu.org to
  submit@emacsbugs.  But since these two mailing-lists are also used
  currently for discussions, we would only want to forward those email
  whose subject doesn't start with "Re:".
  The "Package" should always just be "Emacs" and the "Version" should
  ideally be extracted from the subject (where it should appear in the
  form: "Subject: <version>; <subject>") if present.
  Can you arrange for that to happen?

  I can try to arrange and do it here, tho it's going to be a bit
  fragile (deliver to a special mailbox, then run a cronjob that reads
  this mailbox, then make sure that the cronjob's Kerberos credentials
  are regularly refreshed, ... :-( do I hate Kerberos?).

  Can you arrange to do it directly on your end?


-- Stefan

Re: Bug trackers

[Don Armstrong]

On Tue, 26 Feb 2008, Stefan Monnier wrote:
> I started to play with the emacsbugs thingy (as Richard is stepping down
> as maintainer and was basically doing the bug-tracking himself, I'm
> eager to setup a "new" non-human bug-tracking system) and have some more
> questions:
> 
> - I see that right now, the address emacsbugs@lists.donarmstrong.com is
>   used only for the `emacs' package.  Would it be possible to use it as
>   the default address for each and every package?

Yes, that's just a setting in one of the configuration files. [The
list of known packages is just a set of {packagename,maintainer}
pairs.]

> - how can I manage the email address used as the maintainer of
>   a particular package?  I see I can change the owner of a bug, but
>   I can't see how to manipulate the maintainer of a package.

That's something that the debbugs administrator modifies; it's just
the configuration file above.

> - I see I can "create" a package as a side effect of reassigning a
>   bug to some inexistent package. What about deleting a package or
>   merging it with another one?

You didn't actually create a package like that; you just assigned a
bug to a non-existant package.[1] If you want to get rid of a package,
you just reassign all of its bugs to a different package.

> - As Richard mentioned, we would like/need to forward all
>   bug-reports sent to bug-gnu-emacs@gnu.org and
>   emacs-pretest-bug@gnu.org to submit@emacsbugs. But since these two
>   mailing-lists are also used currently for discussions, we would
>   only want to forward those email whose subject doesn't start with
>   "Re:".

I'll skip that and any bugs with References: and In-Reply-To:.

>   The "Package" should always just be "Emacs" and the "Version" should
>   ideally be extracted from the subject (where it should appear in the
>   form: "Subject: <version>; <subject>") if present.
>   Can you arrange for that to happen?

The Package: bit is already done; the version bit isn't taken care of,
but it would be possible to do.

>   Can you arrange to do it directly on your end?

Are those just mailing lists? If so, it's not that difficult.


Don Armstrong

1: In the ack message you received, there should have been a warning
about how the package didn't have a maintainer and probably isn't the
right package; we don't currently disallow this because in Debian
there are cases where the BTS is behind (usually less than 12 hours)
on the set of packages that are actually uploaded.
-- 
I really wanted to talk to her.
I just couldn't find an algorithm that fit.
 -- Peter Watts _Blindsight_ p294

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Bug trackers

[Stefan Monnier]

>> I started to play with the emacsbugs thingy (as Richard is stepping down
>> as maintainer and was basically doing the bug-tracking himself, I'm
>> eager to setup a "new" non-human bug-tracking system) and have some more
>> questions:
>> 
>> - I see that right now, the address emacsbugs@lists.donarmstrong.com is
>> used only for the `emacs' package.  Would it be possible to use it as
>> the default address for each and every package?

> Yes, that's just a setting in one of the configuration files. [The
> list of known packages is just a set of {packagename,maintainer}
> pairs.]

Then please do that.

>> - how can I manage the email address used as the maintainer of
>> a particular package?  I see I can change the owner of a bug, but
>> I can't see how to manipulate the maintainer of a package.

> That's something that the debbugs administrator modifies; it's just
> the configuration file above.

OK, good.  Since we don't know what packages we'll end up using, having
just a single catch-all address will take care of it for now.

>> - I see I can "create" a package as a side effect of reassigning a
>> bug to some inexistent package. What about deleting a package or
>> merging it with another one?

> You didn't actually create a package like that; you just assigned a
> bug to a non-existant package.[1]

I'm glad I can use non-existent packages like that.  This will allow us
to try-and-use packages before knowing who should be the corresponding
maintainer (or maybe even without ever intending to assign a maintainer
address to it).

I see that `index-packages' does list those non-existent packages, so
other than not having any maintainer is there some downside to them?

> If you want to get rid of a package,
> you just reassign all of its bugs to a different package.

Good.

>> - As Richard mentioned, we would like/need to forward all
>> bug-reports sent to bug-gnu-emacs@gnu.org and
>> emacs-pretest-bug@gnu.org to submit@emacsbugs. But since these two
>> mailing-lists are also used currently for discussions, we would
>> only want to forward those email whose subject doesn't start with
>> "Re:".

> I'll skip that and any bugs with References: and In-Reply-To:.

Great.

>> The "Package" should always just be "Emacs" and the "Version" should
>> ideally be extracted from the subject (where it should appear in the
>> form: "Subject: <version>; <subject>") if present.
>> Can you arrange for that to happen?

> The Package: bit is already done; the version bit isn't taken care of,
> but it would be possible to do.

It will be good to do it, but it's not the top priority, so in case it's
a problem, we can leave it for later.

>> Can you arrange to do it directly on your end?

> Are those just mailing lists? If so, it's not that difficult.

Yes.  You can subscribe to them via http://savannah.gnu.org/mail/?group=emacs

> 1: In the ack message you received, there should have been a warning
> about how the package didn't have a maintainer and probably isn't the
> right package; we don't currently disallow this because in Debian
> there are cases where the BTS is behind (usually less than 12 hours)
> on the set of packages that are actually uploaded.

It looks like a very handy "misfeature" for our use case ;-)


        Stefan


PS: By the way, are you interested in this as an Emacs user as well, or
only as a debbugs developper?

Re: Bug trackers

[Don Armstrong]

On Tue, 26 Feb 2008, Stefan Monnier wrote:
> > Yes, that's just a setting in one of the configuration files. [The
> > list of known packages is just a set of {packagename,maintainer}
> > pairs.]
> 
> Then please do that.

> OK, good. Since we don't know what packages we'll end up using,
> having just a single catch-all address will take care of it for now.

Ok; creating more packages is easy, but I'll have to modify some stuff
to create a default maintainer address for missing packages. I'll try
to get to that later today.
 
> I'm glad I can use non-existent packages like that. This will allow
> us to try-and-use packages before knowing who should be the
> corresponding maintainer (or maybe even without ever intending to
> assign a maintainer address to it).
> 
> I see that `index-packages' does list those non-existent packages,
> so other than not having any maintainer is there some downside to
> them?

That and the "gee, I don't know about that package, you shouldn't
assign bugs to them" message.

> Yes. You can subscribe to them via
> http://savannah.gnu.org/mail/?group=emacs

Ok; Stephen indicated that installing such a handler directly in
mailman was superior, so I'll hold off unless the gnu.org mailman
administrators think differently or won't have time to do this
reasonably soon.
 
> > 1: In the ack message you received, there should have been a warning
> > about how the package didn't have a maintainer and probably isn't the
> > right package; 
>
> It looks like a very handy "misfeature" for our use case ;-)

Yeah, it's easy enough to code around, but it ends up being useful
almost everywhere.

> PS: By the way, are you interested in this as an Emacs user as well,
> or only as a debbugs developper?

I use emacs, but my primary interest is in it as a debbugs developer
and hopefully getting more people interested in developing for debbugs
too.


Don Armstrong

-- 
ou could say to the Universe this is not /fair/. And the Universe
would say: Oh it isn't? Sorry.
 -- Terry Pratchett _Soul Music_ p357

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Bug trackers

[Stefan Monnier]

> Ok; creating more packages is easy, but I'll have to modify some stuff
> to create a default maintainer address for missing packages.  I'll try
> to get to that later today.

Thanks.

>> I'm glad I can use non-existent packages like that. This will allow
>> us to try-and-use packages before knowing who should be the
>> corresponding maintainer (or maybe even without ever intending to
>> assign a maintainer address to it).
>> 
>> I see that `index-packages' does list those non-existent packages,
>> so other than not having any maintainer is there some downside to
>> them?

> That and the "gee, I don't know about that package, you shouldn't
> assign bugs to them" message.

Indeed, in our context, debbugs shouldn't discourage reporting bugs to
packages just on the ground that they don't have a maintainer (of
course, that's only true if/when we get the above mentioned "default
maintainer address").

>> Yes. You can subscribe to them via
>> http://savannah.gnu.org/mail/?group=emacs

> Ok; Stephen indicated that installing such a handler directly in
> mailman was superior, so I'll hold off unless the gnu.org mailman
> administrators think differently or won't have time to do this
> reasonably soon.

I guess we can wait a few more days, indeed.  But the sooner the merrier.
 

        Stefan

Re: Bug trackers

[Stephen J. Turnbull]

Stefan Monnier writes:

 > - As Richard mentioned, we would like/need to forward all bug-reports
 >   sent to bug-gnu-emacs@gnu.org and emacs-pretest-bug@gnu.org to
 >   submit@emacsbugs.  But since these two mailing-lists are also used
 >   currently for discussions, we would only want to forward those email
 >   whose subject doesn't start with "Re:".

I have a Mailman Handler that forwards *from* the Mailman list *to*
the tracker.  It's trivial and safe (ie, can't affect other lists),
thanks to Mailman.

As a matter of policy, I use the presence of References and/or
In-Reply-To headers, rather than contents of the subject line, to
identify replies.

To implement, you need to get the Mailman admin (site admin, can't do
it through the web) to add the Handler to the *list-specific*
pipeline(s).  Please get the relevant person to contact me directly.

Re: Bug trackers

[Richard Stallman]

I asked the sysadmins to write to Stephen and Stefan.

Re: Bug trackers

[Jason Rumney]

Stefan Monnier wrote:
> - As Richard mentioned, we would like/need to forward all bug-reports
>   sent to bug-gnu-emacs@gnu.org and emacs-pretest-bug@gnu.org to
>   submit@emacsbugs.  But since these two mailing-lists are also used
>   currently for discussions, we would only want to forward those email
>   whose subject doesn't start with "Re:".
>   
Normally bugtrackers also hold the subsequent discussion as comments to 
the original report. Why would we not want that?

Re: Bug trackers

[Don Armstrong]

On Tue, 26 Feb 2008, Jason Rumney wrote:
> Stefan Monnier wrote:
>> - As Richard mentioned, we would like/need to forward all bug-reports
>>   sent to bug-gnu-emacs@gnu.org and emacs-pretest-bug@gnu.org to
>>   submit@emacsbugs.  But since these two mailing-lists are also used
>>   currently for discussions, we would only want to forward those email
>>   whose subject doesn't start with "Re:".
>>   
> Normally bugtrackers also hold the subsequent discussion as comments to  
> the original report. Why would we not want that?

The problem is figuring out which report the subsequent discussion is
for or whether it's a new report. If it includes the bug number in the
header, everything happens automatically.[1] If it doesn't, the BTS
assumes you're creating a new report.

It may be that the right way to do things is to intercept new messages
to bug-gnu-emacs@gnu.org, send them first to the bug tracking system,
and send the maintainer messages to the bug-gnu-emacs@gnu.org mailing
list, so that replies are dealt with correctly.... but I don't think
that's something that we want to set up until the maintainers are
reasonably sure that debbugs is good enough for now.


Don Armstrong

1: This is actually a legacy system; normally followup reports go to
bugnum@emacsbugs.donarmstrong.com.
-- 
Il semble que la perfection soit atteinte non quand il n'y a plus rien
a ajouter, mais quand il n'y a plus rien a retrancher.
(Perfection is apparently not achieved when nothing more can be added,
but when nothing else can be removed.)
 -- Antoine de Saint-Exupe'ry, Terres des Hommes

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Bug trackers

[Stefan Monnier]

>> - As Richard mentioned, we would like/need to forward all bug-reports
>> sent to bug-gnu-emacs@gnu.org and emacs-pretest-bug@gnu.org to
>> submit@emacsbugs.  But since these two mailing-lists are also used
>> currently for discussions, we would only want to forward those email
>> whose subject doesn't start with "Re:".
>> 
> Normally bugtrackers also hold the subsequent discussion as comments to the
> original report. Why would we not want that?

AFAIK the bug-tracker will only know into which discussion to place
a reply if the reply is to a message that comes *from* the bugtracker,
rather than merely being a reply to a message that the bugtracker has
also received (i.e. I don't think debbugs will track Message-Ids in
order to classify incoming replies).

So people would/will need to subscribe to
emacsbugs@lists.donarmstrong.com and discuss things there, instead of
discussing them on bug-gnu-emacs.


        Stefan

Re: Bug trackers

[Jason Rumney]

Stefan Monnier wrote:
> AFAIK the bug-tracker will only know into which discussion to place
> a reply if the reply is to a message that comes *from* the bugtracker,
> rather than merely being a reply to a message that the bugtracker has
> also received (i.e. I don't think debbugs will track Message-Ids in
> order to classify incoming replies).
>
> So people would/will need to subscribe to
> emacsbugs@lists.donarmstrong.com and discuss things there, instead of
> discussing them on bug-gnu-emacs.
>   

OK, are we only talking about the test period here? Long term, I think 
we should arrange for the emacs-bug and emacs-pretest-bug aliases to 
feed into the bug tracker only, and all messages to subscribers should 
be sent by the bugtracker with whatever identifying information it needs 
added to the subject line. This will probably take some setting up to 
get right though, so I can understand not wanting to deal with it now 
before we've decided that debbugs meets our needs.

Re: Bug trackers

[Stefan Monnier]

>> AFAIK the bug-tracker will only know into which discussion to place
>> a reply if the reply is to a message that comes *from* the bugtracker,
>> rather than merely being a reply to a message that the bugtracker has
>> also received (i.e. I don't think debbugs will track Message-Ids in
>> order to classify incoming replies).
>> 
>> So people would/will need to subscribe to
>> emacsbugs@lists.donarmstrong.com and discuss things there, instead of
>> discussing them on bug-gnu-emacs.
>> 

> OK, are we only talking about the test period here? Long term, I think we
> should arrange for the emacs-bug and emacs-pretest-bug aliases to feed into
> the bug tracker only, and all messages to subscribers should be sent by the
> bugtracker with whatever identifying information it needs added to the
> subject line. This will probably take some setting up to get right though,
> so I can understand not wanting to deal with it now before we've decided
> that debbugs meets our needs.

Yes, this is the testing period.


        Stefan

Re: Bug trackers

[Stephen J. Turnbull]

Jason Rumney writes:

 > Normally bugtrackers also hold the subsequent discussion as comments to 
 > the original report. Why would we not want that?

Bikeshedding.

Re: Bug trackers

[Jason Rumney]

Stephen J. Turnbull wrote:
> Jason Rumney writes:
>
>  > Normally bugtrackers also hold the subsequent discussion as comments to 
>  > the original report. Why would we not want that?
>
> Bikeshedding.
>   

It happens occasionally on the bug lists, but not often. Usually such 
discussions happen on emacs-devel when new features are proposed, rather 
than in response to bug reports.

Bug trackers

[Richard Stallman]

Has anyone started testing a bug tracker to see what
it is like to use with email?

Re: Bug trackers

[Xavier Maillard]

Hi,

   Has anyone started testing a bug tracker to see what
   it is like to use with email?

There is a good comparison of several tools on wikipedia[1]. The
comparison shows the license of the tool and many mode
informations including the user interface

One of the best I know is debbugs. This is the tool the Debian
team is using everyday for years now. It reliable, stable, easy
to use, has several GNU Emacs centric modes ready to use and it
is free software (off course).

Hope that will help.

	Xavier

[1] http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: Bug trackers

[Richard Stallman]

Would someone like to try using debbugs for Emacs?

Re: Bug trackers

[Xavier Maillard]

   Would someone like to try using debbugs for Emacs?

How ? Where can it be installed ? Does Manoj can explain us how
to set it up ?

Regards,

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

Re: Bug trackers

[Tassilo Horn]

Xavier Maillard <xma@gnu.org> writes:

Hi Xavier,

> One of the best I know is debbugs.

Another free one that can be fully controlled by email is RT [1].
Featurewise it seems to outperform debbugs.

Bye,
Tassilo
__________
[1] http://www.bestpractical.com/rt/

Re: Bug trackers

[Yoni Rabkin]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Xavier Maillard <xma@gnu.org> writes:
>
> Hi Xavier,
>
>> One of the best I know is debbugs.
>
> Another free one that can be fully controlled by email is RT [1].

I don't think that it can be fully controlled via email. I've been using
the gnu.org RT system for a year now and I still need to log into the
Web interface to perform certain actions like "resolving" or "taking" a
ticket.

I'd be very happy to find out that I'm wrong.

-- 
   "Cut your own wood and it will warm you twice"

Re: Bug trackers

[Tassilo Horn]

Yoni Rabkin <yoni@rabkins.net> writes:

Hi Yoni,

>> Another free one that can be fully controlled by email is RT [1].
>
> I don't think that it can be fully controlled via email. I've been
> using the gnu.org RT system for a year now and I still need to log
> into the Web interface to perform certain actions like "resolving" or
> "taking" a ticket.

It seems you're right.  I've read this sentence in the wikipedia article
the other way round.

    RT's primary customer-facing interface is email, while its
    employee-facing interface is Web-based via the Apache HTTP server or
    any other web server or RT own webserver.

Bye,
Tassilo

Re: Bug trackers

[Manoj Srivastava]

On Sat, 16 Feb 2008 09:40:40 +0100, Tassilo Horn <tassilo@member.fsf.org> said: 

> Xavier Maillard <xma@gnu.org> writes: Hi Xavier,

>> One of the best I know is debbugs.

> Another free one that can be fully controlled by email is RT [1].
> Featurewise it seems to outperform debbugs.

        Could you elaborate?  I use debbugs for Debian, and Request
 Tracker for Work;  and I must say I find debbugs far more useful.
 RT does have things like deadlines and tracking time spent on bugs,
 useful for billing and Gantt chart tracking, but rarely gets used
 because of the  fact that most of these features are only accessible
 through the web interface, not email.  Also, we have had issues with
 creating new reports using just email (the nice features of admin-CC
 and CC,  comments, and responses, need the web interface to set up).

        I also wonder about how many of the features of RT (a help desk
 oriented system, where you have "customers" with limited rights and
 visibility, and "staff" with additional rights, and the whole elaborate
 rights management infrastructure) are really important for a project
 like Emacs.

        I think RT has none of the version tracking bits of debbugs, or
 dependencies, blocking bugs, priorities, user defined classifications
 and reports, and even much of a SOAP interface like debbugs does.

        Having used debbugs for its entire lifetime, and having been a
 RT admin now for three years, I must say that I do not agree that RT
 outperforms. 

        manoj
-- 
I did this 'cause Linux gives me a woody.  It doesn't generate
revenue. (Dave '-ddt->` Taylor, announcing DOOM for Linux)
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Bug trackers

[Tassilo Horn]

Manoj Srivastava <srivasta@ieee.org> writes:

Hi Manoj,

>>> One of the best I know is debbugs.
>
>> Another free one that can be fully controlled by email is RT [1].
>> Featurewise it seems to outperform debbugs.
>
>         Could you elaborate?

No, I was wrong.  In the RT wikipedia article I've read that the
users/customers get a web interface and the devs an email interface.
Unfortunately it's the other way round.

Bye,
Tassilo
__________
[1] http://www.chiark.greenend.org.uk/~ian/debbugs/