Re: Migrating to the latest Debbugs version

[Eli Zaretskii]

> From: Felix Lechner <felix.lechner@lease-up.com>
> Cc: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 15 Jan 2024 11:04:37 -0800
> 
> > what this means in practice for us the users of debbugs
> 
> My goal is to keep things unchanged for now. The primary goal is to make
> Debbugs maintainable once again.
> 
> GNU Guix is a functional, declarative package manager. It will make
> tools like Ansible and Puppet obsolete.
> 
> For your perusal, I attached the current packaging for debbugs-gnu
> below.
> 
> > should we expect any changes in the HMI or UX
> 
> No changes should happen when we migrate from Debian with a manually
> maintained code base to a repo-tracked deployment [1] on GNU Guix.
> 
> When we upgrade to the newest version of Debbugs, we will see whatever
> changes upstream made in the past fifteen years.

I understand that you don't know what are those user-visible changes?
But expect them to be minimal, if at all?

> > What about the directives accepted by control@debbugs.gnu.org
> 
> I do not know which changes upstream made in the past fifteen years, if
> any. My sense---from having used the GNU instance for two years and the
> Debian instance thousands of times since 1997---is that the control
> commands stayed more or less the same.
> 
> Are you worried about something in particular?

Mostly the frequently used commands: tags, severity, close, merge,
forcemerge, reopen.

> This migration has three overarching goals.
> 
> 1. Make Debbugs maintainable again
> 2. Encourage contributions
> 3. Upgrade to the latest upstream version
> 
> After a broad consensus among users, we could potentially fork. We would
> then rewrite the bug tracker in Scheme.
> 
> The goal would be to attract contributions from the user base at the
> Emacs and GNU Guix projects, who love the Lambda calculus. We would also
> try to save the Email-based workflow for patch contributions for GNU
> projects that might otherwise switch to collaborative, web-based forges.

I understand, and I have no objections to those goals, of course.  I
just wanted to know whether we should expect the switch to cause any
surprises to people who use the Web UI every day, and if such changes
are expected, to know in advance what kind of changes to expect.

I understand from what you say that the changes should be minimal, if
not nil.  Which I think is ideal: we upgrade to a more maintainable
version without any downsides of the need to learn and get used to s
new UI.

Thanks.