Re: controlling how long before archiving?

[Karl Berry]

Hi Felix,

    Would that issue go away if you were offered, in the search screen, an
    option to inclue bugs that were closed in a selected timeframe

Time-based searching could be nice, but I think the current web search
interface is reasonable. I just have to remember to change the
"Unarchived" dropdown at the bottom. Maybe I'll change my saved urls.

Sorry for lack of quoting, but two other related topics that were
mentioned:

Release-based archiving: since there's currently no way to mark a
release (is there?), it seems moot. But I agree in principle that "28
days after a release" would be better than "28 days after a bug is
closed" (though I'm not entirely sure this is what was being suggested).

Displaying an active bug list: of course none of us want to see tons of
closed bugs. I don't see how the archiving timeframe relates to such
search results.

    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?

    kb> the (huge) project of having a web interface. 
    I'm not sure what you that means 

A web interface that, for example, allows one to open/close,
archive/unarchive, merge/unmerge bugs, instead of doing everything by
mail. (Like I said, I have no expectation that this will happen.)

On an entirely different matter, a more realistic request would be to
automatically include the originator of a bug when replying to
NNNN@debbugs.gnu.org. I am sure originators have missed many messages
intended for them because of this, since I sent many messages myself
before I realized what was going on. And if this is documented anywhere,
I couldn't find it.

    Would you like to be a co-maintainer for Debbugs?

Thanks for asking, but unfortunately, I cannot volunteer for that.

    My hope is to offer a modern alternative to Autoconf and friends

When it comes to automake, my main interest is in retaining
compatibility and keeping automake projects working the way they always
have (in the face of today's ever-more-complex and incompatible
standards, kernels, compilers, etc.). So the idea of Yet Another
alternative does not appeal to me personally, but I expect the Guix
world and others would like it.

Happy hacking,
Karl