Re: controlling how long before archiving?

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: karl@freefriends.org,  felix.lechner@lease-up.com,
>   help-debbugs@gnu.org,  stefankangas@gmail.com
> Date: Thu, 11 Jan 2024 11:21:02 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> >     There was no consensus whether I could fork the Debbugs currently
> >> >     deployed for GNU, or whether I should upgrade to the latest Debbugs
> >> >     upstream version.
> >> >     ... We effectively already do [the fork] with 170 commits on top
> >> >     of upstream.
> >> >
> >> > It's not my call, but it seems to me that if you'd rather work forward
> >> > from the fork instead of the latest with its additional module
> >> > requirements ... why not? Sounds sensible to me. As long as the default
> >> > behavior doesn't change, including for Michael and Emacs, it shouldn't
> >> > cause problems?
> >>
> >> When Felix shows his planned roadmap, we shall contact the Emacs
> >> maintainers for discussion. I have added Eli and Stefan in Cc, in order
> >> to make them aware of it.
> >
> > What is the issue being discussed here.  The Subject seems to say
> > something, but the text in the body doesn't mention that.  What are
> > the reasons for us to fork debbugs?
> 
> Sorry to bring you into the middle of a discussion. The whole thread
> starts at 
> <https://lists.gnu.org/archive/html/help-debbugs/2023-12/msg00013.html>
> and is continued at 
> <https://lists.gnu.org/archive/html/help-debbugs/2024-01/msg00000.html>
> 
> You can access also the mailing list via gmane group gmane.comp.gnu.debbugs.

Thanks.

My take on this is that it's an annoyance to CC a bug report when
discussing some issue, only to get a bounced message in response,
telling me the bug is archived.  IME, this loses quite a few relevant
discussions for the bug db, which we might wish to keep.

Same when someone reports a bug that is a duplicate to an archived
one: not only you must use forcemerge, but you must also unarchive the
bug in that case.

In short, my experience is that this "archiving" feature has only
downsides.  If its only purpose is to prevent spam, then cannot we
prevent it by other means?  GNU mailing lists reject spam quite
efficiently, so why cannot something similar be in place for debbugs?

In any case, I'd support enlarging the time for archiving and
collecting data about any increase in spam.  If spam indeed increases
dramatically, then we know we must do something about it; otherwise we
can stay with a larger archiving delay.

HTH