Hi Zack,
Zack Weinberg wrote:
> Autoconf is currently using the Savannah built-in bug tracker:
> https://savannah.gnu.org/support/?group=autoconf
>
> I'd personally rather be using debbugs, but I don't know why gnu.org
> has two bug trackers in the first place or whether one of them is
> scheduled to be phased out,
A question that I can answer! :-)
Glenn Morris working on Emacs (and I am sure others) wanted to use the
Debian BTS for Emacs rather than the Savannah tracker. Therefore
Glenn talked the FSF admins into setting up a VM debbugs.gnu.org for
the purpose of hosting a GNU instance of the Debian BTS. Then
converted Emacs over to using the BTS.
And once that was set up other people wanted to use the BTS for their
projects too. I remember Jim Meyering jumped at the chance to use it
for Coreutils as an early adopter. And others followed. Quite a few
projects use it now.
We have this list of projects that have been configured for the GNU
BTS instance running on debbugs.
https://debbugs.gnu.org/Packages.html
As you can tell there are quite a few. But it's not all projects.
It's projects that have asked for it. No one is pushing the BTS upon
projects. But certainly if anyone wants to use it then it is
available for their use. And also the Savannah tracker is also
available for use.
There is no effort to push anyone to any particular tool. It is
completely up to the maintainers to choose. And there is no plan to
phase out either of the trackers.
> and anyway I think a release freeze is not the time to be changing
> trackers.
No disagreement or complaints. The question was simply about the best
thing to do since we had this bug come into the automake tracker and
reassigned to the autoconf tracker, and fell into the pitfall that is
autoconf does not use the BTS on debbugs, generated warnings which
Karl noticed due to this, and got me involved since I am involved in
both of them.
If autoconf is going to use the BTS in the future, which I only
mention because you said you would rather be using it, then let's do
nothing for the moment. Then it can use it in the future. Leave the
bugs assigned to the unregistered autoconf project in the BTS. And
just handle them normally. The submitter won't know the difference.
The BTS is only generating warnings as a typo protection against
assigning to a non-existent typo error. The only important thing is
that maintainers need to know to look there since it is at this moment
not an expected place for bugs to show up.
If autoconf is not going to use the BTS in the future then we should
empty the BTS autoconf tickets. Open a new ticket in the Savannah
tracker for each of them, paste in all of the appropriate data, and
close the one in the debbugs BTS. That way we don't have dangling
tickets that no one will ever see. And if we don't close out the
autoconf bugs in the BTS then people will see open bugs there and add
more bugs there! We should empty it so that it doesn't look available
for use there.
Or any other process flow that makes sense to you.
> I did see the bug you want to reassign to autoconf and I intend to
> look at it this weekend.
Bob
