help-debbugs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: controlling how long before archiving?


From: Felix Lechner
Subject: Re: controlling how long before archiving?
Date: Sun, 31 Dec 2023 15:28:00 -0800

Hi Karl,

On Sun, Dec 31 2023, Karl Berry wrote:

> How about six months? A year? Five years?

The term "archiving" may be a misnomer. It simply means that no more bug
amendments are accepted. The reports are still available online.

I was thinking maybe two months.

> I don't understand how the quick archiving helps with spam?

Archived bugs accept no amendments, so spam is rejected.

> filtering surely has to happen in other place(s), not relying on
> whether a bug is archived.


> (Because then spam would come through to all the current bugs which,
> thankfully, it doesn't.)

The Debian instance receives a fair amount of spam.

> The main visible change I can imagine is taking longer for bugs to
> "disappear" from the online reports -- the disappearance is another
> thing I find confusing rather than helpful, but I recognize it's been
> that way forever, so change might not be welcome.

Disappear from where, please? You mean that you have to chose archived
bugs in the search criteria?

> further issues arise related to the bug, which can easily happen
> months or years later ...It seems better to add to the relevant
> existing bug than start a new one.

As someone who has closed and commented on hundreds of bug reports at
Debian, I am not sure that reopening bugs is good practice unless the
fix was clearly defective.

The reading burden can be enormous when there are a dozen or more prior
commends. Instead, I would quote the earlier bug report. That leaves a
clear trail in commit messages and changelog entries as to which bug was
thought to have been closed when, and how.

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

As a side note, I hope to fork Debbugs for GNU but there is no
consensus. With Guix and Emacs we have special needs to serve. Upstream
is more in a maintenance mode, I think. Then we could entertain all
manner of bug fixes.

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.

Base on the mention of your name here [1] I would give special
consideration to your suggestions!

Are you the Automake maintainer?

Kind regards
Felix

[1] https://www.gnu.org/people/people.en.html



reply via email to

[Prev in Thread] Current Thread [Next in Thread]