-- 

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