From: Josselin Poiret <dev@jpoiret.xyz>
To: Giovanni Biscuolo <g@xelera.eu>
Cc: guix-devel@gnu.org
Subject: Re: on the bug tracker (Re: Guix Days: Patch flow discussion)
Date: Sat, 09 Mar 2024 10:39:23 +0100 [thread overview]
Message-ID: <87plw3n3qs.fsf@jpoiret.xyz> (raw)
In-Reply-To: <875xy74ono.fsf@xelera.eu>
[-- Attachment #1: Type: text/plain, Size: 4603 bytes --]
--
Giovanni Biscuolo <g@xelera.eu> writes:
> 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.
We can re-use some other tool as well, no need to code our own in Guile
though. Also note that the choice of bug-tracking tool is not benign,
as most other tools (Mumi, but also QA) have to adapt to its
idiosyncrasies.
> In other words: the "problem" it's not the tool, it's the *interface*.
I don't agree: see below for the two examples of where the tool design
itself is problematic.
> 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.
I prefer a public-inbox web frontend for browsing emails personally.
>> 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 don't think there's a "public" discussion of this, but I've conversed
with the mailman maintainers in private about this: because Debbugs
relies on modifying the mail message itself, it clashes with modern
email features that authentify received emails.
DKIM authentifies a subset of mail headers by signing them with a
private key, among which the "From" header is mandatory. DMARC is a
policy mechanism for domains that can enforce DKIM (and/or SPF) for all
mails with a corresponding "From:". Together, they prevent email
impersonation.
So Debbugs modifies a protected header (e.g. Subject) -> DKIM fails ->
if DMARC is set to enforce DKIM, DMARC fails -> mail is not received.
To avoid this issue, Mailman (the mailing daemon overseeing the
debbugs-managed MLs) also rewrites the From: header of such mails to a
debbugs-controlled domain, so that DKIM headers can be re-signed and a
different DMARC policy be used. This is why you often see "via
guix-patches" in From: headers, and if you look at the email it's a
generic one.
I've also mentioned this before, but not being able to simply send a
full patchset without having to go through hoops is, put simply, a
problem. Even prospective contributors used to email-based workflows
will be turned off by this.
In general, the problem with Debbugs is that it insists on *taking over*
emails, rather than just consuming them.
>> 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.
Yes, I was mentioning general tools.
> 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]
I like this separation as well, and Tissue seemed interesting the last
time I looked at it. I liked how it uses standard tools and can be
consulted/modified off-line. It basically checks all of the boxes :)
Best,
--
Josselin Poiret
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 682 bytes --]
prev parent reply other threads:[~2024-03-09 9:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-05 18:44 Guix Days: Patch flow discussion Suhail
2024-02-05 19:59 ` Hartmut Goebel
2024-02-06 11:14 ` Josselin Poiret
2024-02-06 13:57 ` Debbugs update (Was: Guix Days: Patch flow discussion) Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-02-06 21:14 ` Ricardo Wurmus
2024-02-29 9:15 ` on the bug tracker (Re: " Giovanni Biscuolo
2024-03-09 9:39 ` Josselin Poiret [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87plw3n3qs.fsf@jpoiret.xyz \
--to=dev@jpoiret.xyz \
--cc=g@xelera.eu \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).