guix-devel
[Top][All Lists]
Advanced

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

on the bug tracker (Re: Guix Days: Patch flow discussion)


From: Giovanni Biscuolo
Subject: on the bug tracker (Re: Guix Days: Patch flow discussion)
Date: Thu, 29 Feb 2024 10:15:23 +0100

Hi Josselin,

Josselin Poiret <dev@jpoiret.xyz> writes:

[...]

> One thing I would like to get rid of though is debbugs.

given that a significant part of the Guix infrastructure is provided by
the GNU project, including the bug/issue tracker, and I don't think that
GNU will replace https://debbugs.gnu.org/ (or the forge, Savannah) with
something else, I suggest to concentrate the Guix community efforts in
giving contributors better user interfaces to Debbugs, e.g Mumi (web and
CLI) instead of trying to get rid of it.

In other words: the "problem" it's not the tool, it's the *interface*.

Please also consider that if (I hope not) the Guix would decide to adopt
a different bug/issue tracker system then Someome™ will have to
administrate it, and currently there are other pieces of core
infrastructure that need more resources, e.g. QA.

Speaking of interface features, I simply *love* the email based
interface provided by Debbugs [1]; also the web UI is not bad, and the Mumi
one (https://issues.guix.gnu.org/) it's even better.

But I'm curious: what bug tracker would you suggest instead of Debbugs?

Let's see what some "big players" are using...

> It causes a lot of pain for everyone, eg. when sending patchsets, it
> completely breaks modern email because it insists on rewriting
> DMARC-protected headers, thus needing to also rewrite "From:" to avoid
> DMARC errors.

I don't understand what "completely breaks modern email" means: please
could you point me to a document where this issue/bug is documented?

> I've been following the Linux kernel development a bit closer this past
> year, and while there are things that need to improve (like knowing the
> status of a patchset in a maintainer's tree), they at least have a lot
> of tools that I think we should adopt more broadly:

you mention: b4/lei and patchwork but they are not bug/issue trackers.

the Linux kernel community is using https://bugzilla.kernel.org/;
RedHat, Fedora, OpenSUSE and SUSE are also using Bugzilla

Arch Linux have adopted GitLab issues

Other alternavives:
https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems

...or:
https://en.wikipedia.org/wiki/Bug_tracking_system#Distributed_bug_tracking

I personally like the idea that the bug/issue tracker is _embedded_
(integrated?) in the DVCS used by the project, Git in Guix case.

For this reason I find Tissue https://tissue.systemreboot.net/ an
interesting project for *public* issue/bug tracking systems, also
because Tissue is _not_ discussion-oriented: this means that
discussions are managed "somewhere else", because «It's much better to
have a clear succinct actionable issue report. This way, the issue
tracker is a list of clear actionable items rather than a mess of
unreproducible issues.»  [2]

Happy hacking! Gio'

[...]

[1] https://debbugs.gnu.org/server-control.html

[2] https://tissue.systemreboot.net/manual/dev/en/#section11795

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

Attachment: signature.asc
Description: PGP signature


reply via email to

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