Re: controlling how long before archiving?

[Karl Berry]

Hi Felix,

    I was thinking maybe two months.

Fine by me. Any increase is helpful, as far as I'm concerned.

    Archived bugs accept no amendments, so spam is rejected.

I get that part, but my thought was that just as much if not more spam
would be coming into current bugs. So spam filtering has to happen
somewhere else, and not just rely on archival of bugs.

    The Debian instance receives a fair amount of spam.

I've never known where spam filtering is happening for debbugs.gnu.org,
but it must be happening somewhere. I expect the FSF has some sort of
filtering set up for all incoming mail (I know they do for incoming to
lists.gnu.org), but I also expect that's not enough, based on the amount
of spam I see coming in for lists.gnu.org past the FSF filters. Yet,
happily, I have never seen a single spam message come through to the
debbugs.gnu.org reports. Anyway, this is another topic :).

    Disappear from where, please? 

E.g.
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake

I can understand not wanting to see bugs that are years old in the
online report, but I've been puzzled more than once about bugs that I
know exist not being there, before I remember that archived bugs have
be included in the search separately, via the toggle at the bottom of
the page or otherwise.

    You mean that you have to chose archived bugs in the search criteria?

Right. 

    I am not sure that reopening bugs is good practice unless the
    fix was clearly defective.

I see. I appreciate that advice, and am happy to follow it.

    Conversely, people tend to close duplicates that should actually be
    merged.

Well, I can understand that, and indeed, I do it myself :(.

(The failure of) merging is yet another topic. I've pretty much giving
up on merging except in the simplest possible cases (someone sends in
essentially the same report multiple times), because the criteria for
merging is so strict.

So then I tried forcemerge, and that failed too, and the system did not
tell me what the problem was. At least not that I recall from the last
time I tried.  Quite discouraging.  Sorry, I don't remember what I was
doing or what bugs were involved, so this is not a helpful report, but
that's where I am ...

I could probably figure out the failure(s) eventually, but I don't want
to spend that time. I already have many more actual bugs to fix than I
have time for, so any time spent fighting with the bug system is not
well spent. So much easier just to mention the relevant bug numbers and
close.

    I hope to fork Debbugs for GNU but there is no consensus.

Consensus about what?

If you have the time and energy to do the work, I think you get to
decide ... within reason, anyway. I imagine some other vhost parallel to
debbugs.gnu.org could be set up for testing on gnu.org.

    On that note, I have an experimental deployment of the reconstructed
    code for Debbugs on GNU Guix at https://debbugs.juix.org.
    ...
    I am also working on the latest upstream version. Ultimately, I
    would like to bring changes to the GNU version that upstream will
    not accept.

I am impressed with your efforts and plans :).

    Base on the mention of your name here

:). I'm just happy anyone is interested in working on debbugs.

FWIW, the number one thing that I think would make a difference (but
have no expectation of it getting implemented) is the (huge) project of
having a web interface. Which I know has come up zillions of times
before. Having implemented several bug systems myself, I know how much
work it is ... :).
    
    Are you the Automake maintainer?

Well, Jim (Meyering) is the official maintainer and has made all the
recent releases, but yeah, for the last couple of years, I have been the
most active person in coordinating/installing patches and trying to fix
enough stuff to keep automake going.

Happy bug hacking,
Karl