Re: controlling how long before archiving?

[Felix Lechner]

Hi Karl,

On Mon, Jan 01 2024, Karl Berry wrote:

> So spam filtering has to happen somewhere else, and not just rely on
> archival of bugs.

I totally agree.

> 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

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 (for
example, two years)..

> So then I tried forcemerge, and that failed too, and the system did not
> tell me what the problem was.

I saw your thread here [1] and will comment there shortly, but both
49901 and 60419 were merged as you instructed.

> Consensus about what?

Consensus about deploying a fork of Debbugs. We effectively already do
so [2] with 170 commits on top of upstream.

> If you have the time and energy to do the work, I think you get to
> decide ... within reason, anyway.

I'm a good candidate because I revamped Debian's lintian.org from a Perl
site into a modern web application (with a Postgres backend). That site
was exactly in the same state as Debbugs is now.

I know exactly what to do, even if we stick with Perl.

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.

While the latter sounds attractive in theory, it requires four times as
many Perl modules, uses the same custom-made, PHP-like templates and
still does not serve valid HTML.

Either way, I gave in and packaged the latest version, as well. It is
deployed at better.juix.org, but is in rough shape because it currently
works off of the current configuration and data files (for a version
that is fifteen years old)..

> I imagine some other vhost parallel to debbugs.gnu.org could be set up
> for testing on gnu.org.

I will present a transition plan shortly, but I have to convince FSF to
deploy GNU Guix instead of Trisquel. Scheme all around!

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

I'd love to help the community I admire.

> 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.

I'm not sure what you that means but after the fork I'd be happy to look
at all merge requests! Would you like to be a co-maintainer for Debbugs?

> 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.

I wrote a Ninja-style build system that uses Scheme files as input. [3]
It's in rough shape but already has some Autoconf integration and also
Automake functionality. My hope is to offer a modern alternative to
Autoconf and friends, all of which I love and have used since the
mid-1990's, but with GNU Guile instead of m4.

GCC and many other projects would never switch because of their
bootstrapping needs but others, including GNU Guix, would probably run
with it. What do you think about that plan, please?

Kind regards
Felix

[1] https://mail.gnu.org/archive/html/help-debbugs/2023-05/msg00007.html
[2] https://codeberg.org/lechner/debbugs-gnu
[3] https://codeberg.org/lechner/bespoke