Re: [coreutils] debbugs

[Glenn Morris]

> > 1) Change the automake maintainer to bug-automake
> > 
> > 2) Activate a router rule for bug-automake, that would redirect
> > messages to debbugs.gnu.org. This should happen automatically once I
> > add an entry to the appropriate config file on debbugs.gnu.org (has not
> > been tested yet, but should work).
> 
> Please do that.  Thanks!

OK, done. In theory the router rule should take effect in the next hour.

Re: [coreutils] debbugs

[Ralf Wildenhues]

Hello Glen, all, and sorry for the long delay,

* Glenn Morris wrote on Thu, Oct 14, 2010 at 01:54:45AM CEST:
> Ralf Wildenhues wrote (on Wed, 13 Oct 2010 at 22:46 +0200):
> 
> > There is one question I haven't seen addressed yet, that I think should
> > be documented: is it possible to easily export the bug database to some
> > other format?  Are there maybe any converters that do this already?
> > (I'm thinking that it should be possible, but if one has to completely
> > invent it anew, that would at least be some work.)
> 
> Hmm. I don't know - there might be some Debian tools to do that?
> 
> The bugs can be retrieved as mbox folders via the web-interface, eg:
> http://debbugs.gnu.org/cgi/bugreport.cgi?mboxmaint=yes;mbox=yes;bug=7209
> 
> Internally, they are all stored as basically mbox mail folders with
> some extra sections inbetween the messages. There are two extra files
> that summarize the status. Everything is plain text.

Let's ignore all of this, I don't think it warrants delaying the switch.

> > I think we want this.  Does bug-coreutils operate in Exclusive mode?
> 
> Yes, it does. By the way, that is just a term I made up. :)

Fine with me.

> > I think that is what would be easiest for bug-automake as well.
> 
> I agree.

OK then.

> > You can use my email address as maintainer and debbugs-submit moderator
> > for now. 
> 
> Done. "automake" exists as a package now, and I filed a test bug:
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7209
> 
> You should get a mail about it. You can play around with replying,
> setting severity, closing, etc.

That's all good.  Thanks.

> When you are ready to go ahead, the final steps would be to:
> 
> 1) Change the automake maintainer to bug-automake
> 
> 2) Activate a router rule for bug-automake, that would redirect
> messages to debbugs.gnu.org. This should happen automatically once I
> add an entry to the appropriate config file on debbugs.gnu.org (has not
> been tested yet, but should work).

Please do that.  Thanks!

> > My current plan is to apply the patch below to the tree, create the HTML
> > page from it and upload it to
> > 
> > (where it will appear for the next release anyway), so you could use
> > that as "Specific help" link on .
> 
> > +...@uref{http://debbugs.gnu.org/@/cgi/@/pkgreport.cgi?package=automake;max-bugs=100;base-order=1;bug-rev=1,
> > +bug tracker}.
> 
> May be better to simply use http://debbugs.gnu.org/automake there.

Good idea.  I've uploaded the fixed text to above URL now, will push the
commit soon.

Thanks,
Ralf

Re: [coreutils] debbugs

[Glenn Morris]

Hi,


Ralf Wildenhues wrote (on Wed, 13 Oct 2010 at 22:46 +0200):

> Thank you for this writeup, also for the other documentation accessible
> from the toplevel and http://debbugs.gnu.org/Developer.html.

Most of that is generic Debbugs documentation, by the way.

> There is one question I haven't seen addressed yet, that I think should
> be documented: is it possible to easily export the bug database to some
> other format?  Are there maybe any converters that do this already?
> (I'm thinking that it should be possible, but if one has to completely
> invent it anew, that would at least be some work.)

Hmm. I don't know - there might be some Debian tools to do that?

The bugs can be retrieved as mbox folders via the web-interface, eg:
http://debbugs.gnu.org/cgi/bugreport.cgi?mboxmaint=yes;mbox=yes;bug=7209

Internally, they are all stored as basically mbox mail folders with
some extra sections inbetween the messages. There are two extra files
that summarize the status. Everything is plain text.

> Then, if there is an importer, we might want to consider importing the
> old Gnats database bugs.  I don't even know whether exporting from
> Gnats is possible, though.

Again, I am not aware of any importer, but there might be one. If not,
it's probably doable, but I not sure how much work it would be.

> I think we want this.  Does bug-coreutils operate in Exclusive mode?

Yes, it does. By the way, that is just a term I made up. :)

> I think that is what would be easiest for bug-automake as well.

I agree.

> You can use my email address as maintainer and debbugs-submit moderator
> for now. 

Done. "automake" exists as a package now, and I filed a test bug:

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

You should get a mail about it. You can play around with replying,
setting severity, closing, etc.

> The bug-automake list is known under its name only, as far as I know.

OK.

When you are ready to go ahead, the final steps would be to:

1) Change the automake maintainer to bug-automake

2) Activate a router rule for bug-automake, that would redirect
messages to debbugs.gnu.org. This should happen automatically once I
add an entry to the appropriate config file on debbugs.gnu.org (has not
been tested yet, but should work).

> My current plan is to apply the patch below to the tree, create the HTML
> page from it and upload it to
> 
> (where it will appear for the next release anyway), so you could use
> that as "Specific help" link on .

> +...@uref{http://debbugs.gnu.org/@/cgi/@/pkgreport.cgi?package=automake;max-bugs=100;base-order=1;bug-rev=1,
> +bug tracker}.

May be better to simply use http://debbugs.gnu.org/automake there.

Re: [coreutils] debbugs

[Ralf Wildenhues]

[ adding automake-patches ]

Hi Glen,

sorry for the delay.

* Glenn Morris wrote on Mon, Sep 27, 2010 at 09:17:08AM CEST:
> > > With that in mind, I'm looking for something that can keep things in
> > > order in some way, be that things added by users or ourselves.
> > > Who do we talk to if we want to try it out?
> > 
> > Glenn Morris is the guy.  He set up the emacs one and then made it so
> > that with almost no work we could use it for coreutils, too.
> 
> You are very welcome to try it out, and you prompted me to create a
> web-page explaining how it works:
> 
> http://debbugs.gnu.org/Using.html

Thank you for this writeup, also for the other documentation accessible
from the toplevel and http://debbugs.gnu.org/Developer.html.

There is one question I haven't seen addressed yet, that I think should
be documented: is it possible to easily export the bug database to some
other format?  Are there maybe any converters that do this already?
(I'm thinking that it should be possible, but if one has to completely
invent it anew, that would at least be some work.)

Then, if there is an importer, we might want to consider importing the
old Gnats database bugs.  I don't even know whether exporting from
Gnats is possible, though.

> Let me know if you have any questions.

I think we want this.  Does bug-coreutils operate in Exclusive mode?
I think that is what would be easiest for bug-automake as well.

You can use my email address as maintainer and debbugs-submit moderator
for now.  The bug-automake list is known under its name only, as far as
I know.

My current plan is to apply the patch below to the tree, create the HTML
page from it and upload it to

(where it will appear for the next release anyway), so you could use
that as "Specific help" link on .

Comments regarding the patch, and the general strategy of course,
appreciated.

Thanks,
Ralf

Add FAQ entry for bug reporting instructions.

* doc/automake.texi (Reporting Bugs): New section.
(Introduction): Refer to it.

diff --git a/doc/automake.texi b/doc/automake.texi
index e107e2c..c93e563 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -343,6 +343,7 @@ Frequently Asked Questions about Automake
 * Multiple Outputs::Writing rules for tools with many output files
 * Hard-Coded Install Paths::Installing to hard-coded locations
 * Debugging Make Rules::Strategies when things don't work as expected
+* Reporting Bugs::  Feedback on bugs and feature requests
 
 History of Automake
 
@@ -424,8 +425,7 @@ to be built.
 @cindex Reporting bugs
 @cindex E-mail, bug reports
 
-Mail suggestions and bug reports for Automake to
-...@email{@value{PACKAGE_BUGREPORT}}.
+For more information on bug reports, @xref{Reporting Bugs}.
 
 @node Autotools Introduction
 @chapter An Introduction to the Autotools
@@ -10401,6 +10401,7 @@ lists.
 * Multiple Outputs::Writing rules for tools with many output files
 * Hard-Coded Install Paths::Installing to hard-coded locations
 * Debugging Make Rules::Strategies when things don't work as expected
+* Reporting Bugs::  Feedback on bugs and feature requests
 @end menu
 
 @node CVS
@@ -11793,6 +11794,47 @@ a debugger.
 @end itemize
 
 
+...@node Reporting Bugs
+...@section Reporting Bugs
+
+Most nontrivial software has bugs.  Automake is no exception.  Although
+we cannot promise we can or will fix a bug, and we might not even agree
+that it is a bug, we want to hear about problems you encounter. Often we
+agree they are bugs and want to fix them.
+
+To make it possible for us to fix a bug, please report it. In order to
+do so effectively, it helps to know when and how to do it.
+
+Before reporting a bug, it is a good idea to see if it is already known.
+You can look at the @uref{http://debbugs.gnu.org/, GNU Bug Tracker}
+and the @uref{http://lists.gnu.org/@/archive/@/html/@/bug-automake/,
+bug-automake mailing list archives} for previous bug reports.  We
+previously used a
+...@uref{http://sourceware.org/@/cgi-bin/@/gnatsweb.pl?database=automake,
+Gnats database} for bug tracking, so some bugs might have been reported
+there already.  Please do not use it for new bug reports, however.
+
+If the bug is not already known, it should be reported.  It is very
+important to report bugs in a way that is useful and efficient.  For
+this, please familiarize yourself with
+...@uref{http://www.chiark.greenend.org.uk/@/~sgtatham/@/bugs.html, How to
+Report Bugs Effectively}
+and @uref{http://catb.org/@/~esr/@/faqs/@/smart-questions.html, How to
+Ask Questions the Smart Way}.  This helps you and developers to save
+time which can then be spent on fixing more bugs and implementing more
+features.
+
+For a bug report, a feature request or other suggestions, please send
+email to to @ema...@value{package_bugreport}}.  This will then open a
+new bug in the
+...@ur

Re: [coreutils] debbugs

[Glenn Morris]

Hi,

> > With that in mind, I'm looking for something that can keep things in
> > order in some way, be that things added by users or ourselves.
> > Who do we talk to if we want to try it out?
> 
> Glenn Morris is the guy.  He set up the emacs one and then made it so
> that with almost no work we could use it for coreutils, too.

You are very welcome to try it out, and you prompted me to create a
web-page explaining how it works:

http://debbugs.gnu.org/Using.html

Let me know if you have any questions.

Re: [coreutils] debbugs

[Jim Meyering]

Ralf Wildenhues wrote:
> [ sorry for the xpost; please followup to the automake list, replyto set ]
>
> Hello coreutils developers,
>
> Gary was nice to point us at the debbugs you're using now for your bugs
> list.  How do you like it, how's it working for you,

Hi Ralf, yes I'm happy with it.

> it can be worked with email only, right?

Yes, that was a big selling point for me.

> Automake has its Gnats, mostly unused and feature-poor, I don't like it
> much, and with Libtool, we've never been able to consistently use a bug
> tracker, either.  The Savannah bug/patch tracker require lots of
> clicking and waiting for web scripts to ponder, that's not so much fun.
>
> Also, the number of unresolved bugs in autotools packages tends to
> infinity in the long run (not monotonically, but let's be honest, there
> are always more issues than we can address, be they bugs in the
> autotools themselves or in the way users use them, or in third-party
> packages).
>
> With that in mind, I'm looking for something that can keep things in
> order in some way, be that things added by users or ourselves.
> Who do we talk to if we want to try it out?

Glenn Morris is the guy.  He set up the emacs one and then made it so
that with almost no work we could use it for coreutils, too.