unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Re: Guix Days: Patch flow discussion
@ 2024-02-05 18:44 Suhail
  2024-02-05 19:59 ` Hartmut Goebel
  0 siblings, 1 reply; 5+ messages in thread
From: Suhail @ 2024-02-05 18:44 UTC (permalink / raw)
  To: Hartmut Goebel; +Cc: guix-devel

Hartmut Goebel <h.goebel@crazy-compilers.com> writes:

> This list is missing one point - which has been discussed several
> times already without any result:
>
> The current mail-based workflow is too complicated for new and
> occasional committers.

Could you please share a reference where the key difficulties you
encountered wrt the "current mail-based workflow" are summarized.  Is
the difficulty regd. checking out the code at the right commit and
installing the patches, or something else?

-- 
Suhail



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Guix Days: Patch flow discussion
  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
  0 siblings, 1 reply; 5+ messages in thread
From: Hartmut Goebel @ 2024-02-05 19:59 UTC (permalink / raw)
  To: Suhail; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]

Am 05.02.24 um 19:44 schrieb Suhail:
> Could you please share a reference where the key difficulties you
> encountered wrt the "current mail-based workflow" are summarized.  Is
> the difficulty regd. checking out the code at the right commit and
> installing the patches, or something else?

It's not only installing and testing the patches, but also

  * when has this issue/patch been worked on last - is somebody
    currently working on it
  * what issue/patches I started to review?
  * commenting on code requires to download the patch - strip out parts
    which are okay, comment, then mail the commented code to the correct
    issue number
  * Even when using the debbugs interface in emacs
      o It is is hard to use for occasional users
      o It is an insurmountable obstacle for those not using emacs.
      o It does not tell what issues/patches I've been working on
        already - and waiting for a reply
      o It does not tell which issues are stale

Anyhow, all of this has been discussed several times already. And as 
long as vocal (and active :-) members of the community insist on being 
able to work via e-mail — while also not adopting modern e-mail-capable 
forges — this situation will not change.

Regards
Hartmut Goebel

| Hartmut Goebel          |h.goebel@crazy-compilers.com                |
|www.crazy-compilers.com  | compilers which you thought are impossible |

[-- Attachment #2: Type: text/html, Size: 2090 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Guix Days: Patch flow discussion
  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.
  0 siblings, 1 reply; 5+ messages in thread
From: Josselin Poiret @ 2024-02-06 11:14 UTC (permalink / raw)
  To: Hartmut Goebel, Suhail; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

Hi Hartmut,

Hartmut Goebel <h.goebel@crazy-compilers.com> writes:

> Anyhow, all of this has been discussed several times already. And as 
> long as vocal (and active :-) members of the community insist on being 
> able to work via e-mail — while also not adopting modern e-mail-capable 
> forges — this situation will not change.

While I agree with your assessment of what's missing in this workflow,
I'm not sure I know of any e-mail-capable forges that resolve those
particular pain points…  People often think that eg. sr.ht works better
for this, but I don't think the sr.ht MLs have any more structure than
what we have.  For smaller projects, it works okay, but once you get to
the scale of something like Guix, it doesn't offer anything more.

One thing I would like to get rid of though is debbugs.  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'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:

b4/lei is a nice example (we already have yhetil.org as a back-end, but
maybe a more blessed one would be better) of a tool that lets you
completely automate applying a patchset to a branch.

patchwork is a nice tool to gather up and track patchsets, with status
indicators like "under review", "accepted", etc.  Chris already deploys
one as part of QA, more integration with it would be nice.

One advantage of this is that we would benefit from upstream's bigger
user-base and dev time, and also from the fact that these tools are made
to work together (b4 can automatically mark patchsets as accepted)!

Best,
-- 
Josselin Poiret

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 682 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Debbugs update (Was: Guix Days: Patch flow discussion)
  2024-02-06 11:14   ` Josselin Poiret
@ 2024-02-06 13:57     ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
  2024-02-06 21:14       ` Ricardo Wurmus
  0 siblings, 1 reply; 5+ messages in thread
From: Felix Lechner via Development of GNU Guix and the GNU System distribution. @ 2024-02-06 13:57 UTC (permalink / raw)
  To: Josselin Poiret, Hartmut Goebel, Suhail; +Cc: guix-devel

Hi Hartmut & Josselin,

On Mon, Feb 05 2024, Hartmut Goebel wrote:

> Am 05.02.24 um 10:39 schrieb Steve George:
>
> [order of quotations reversed]
>
> The current mail-based workflow is too complicated ... which has been
> discussed several times already without any result:

Well, that's not totally true. After hearing the plight last year, I
offered the FSF to assume responsibility for debbugs.gnu.org. [1]

I also packaged and deployed on GNU Guix

  (A) the fifteen-year old Debbugs version deployed at gnu.org [2][3][4]
  (B) the modern Debbugs version deployed at debian.org [5][6][7]
  (C) and a custom version of Mumi for my own bug fixes [8][9]

Together with the official debbugs.gnu.org, which runs on Debian 8, and
issues.guix.gnu.org, I am now working to fold all five deployments into
one.

On Tue, Feb 06 2024, Josselin Poiret wrote:

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

I can do little to appease the hardcore Debbugs haters, but I have a
vision for a bug tracking system that, written in GNU Guile, will
attract less wholesale criticism and more constructive contributions
from from the Emacs and Guix communities, which are the primary users of
debbugs.gnu.org.

Both groups are already in love with the lambda calculus.

Mumi made great steps in that direction but has so far not attracted the
contributions it deserves.

In another piece of the puzzle, Michael Albinus wrote and maintains an
excellent Emacs package called Debbugs.el. It allows bug work to take
place in Gnus and Org Modes [10] rather than in a web browser. With that
package, Emacs could become a favorite way to work on our bugs and
patches, similar to what Magit did for Git.

At Guix, folks also do not use Debbugs to its full potential. Git hooks
are an example. Mumi obscures some features. I know because I worked on
Debian's bugs for many years.

I am committed to Debbugs because I'm not sure interactions between
people can be audited properly on modern development forges. For many
years, I worked with Salsa, Debian's Gitlab instance. While convenient,
it was difficult to find past conversations and code snippets, although
like Josselin I'm watching what the kernel folks are doing.

The databases in forges are also complicated to maintain. Plus, projects
experience immediate vendor lock in.

My primary hurdle with modernizing Debbugs, if anyone cares, is that the
FSF is reluctant to deploy GNU Guix. They insist on Trisquel plus
Ansible [11] which is what they have been using for some time.

Thank you, everyone, for your hard work on GNU Guix!

Kind regards
Felix

[1] https://lists.nongnu.org/archive/html/help-debbugs/2023-10/msg00003.html
[2] https://debbugs.juix.org/cgi/bugreport.cgi?bug=66703
[3] https://codeberg.org/lechner/juix/src/commit/5fffdb0053b18b4b28adadbbebb79a1d9bfe2337/juix/deploy/debbugs.scm#L1046-L1184
[4] https://codeberg.org/lechner/debbugs-gnu
[5] https://better.juix.org/cgi/bugreport.cgi?bug=66703
[6] https://codeberg.org/lechner/juix/src/commit/5fffdb0053b18b4b28adadbbebb79a1d9bfe2337/juix/deploy/debbugs.scm#L1186-L1364
[7] https://salsa.debian.org/debbugs-team/debbugs
[8] https://mumi.juix.org/66703
[9] https://codeberg.org/lechner/mumi
[10] https://elpa.gnu.org/packages/doc/debbugs-ug.html
[11] https://lists.nongnu.org/archive/html/help-debbugs/2024-01/msg00049.html


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Debbugs update (Was: Guix Days: Patch flow discussion)
  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
  0 siblings, 0 replies; 5+ messages in thread
From: Ricardo Wurmus @ 2024-02-06 21:14 UTC (permalink / raw)
  To: Felix Lechner; +Cc: Josselin Poiret, Hartmut Goebel, Suhail, guix-devel


Hi Felix,

> I also packaged and deployed on GNU Guix
>
>   (A) the fifteen-year old Debbugs version deployed at gnu.org [2][3][4]
>   (B) the modern Debbugs version deployed at debian.org [5][6][7]
>   (C) and a custom version of Mumi for my own bug fixes [8][9]
>
> Together with the official debbugs.gnu.org, which runs on Debian 8, and
> issues.guix.gnu.org, I am now working to fold all five deployments into
> one.

Let me just pop in to say thank you for that.  I appreciate you taking
the time to talk to Debbugs / GNU folks to work through the obstacles
that the current situation with the GNU fork of Debbugs presents us
with.

I don’t want to add weight to the scales on either side (a future with
or without Debbugs), but I think it is important to identify the actual
limitations and opportunities of the existing platform and chart the
shortest route around them.

It’s how we ended up with mumi in the first place, and I’m hopeful that
this approach can get us to a better place when it comes to tooling.

(The biggest chunk of the problem may well be a social issue, that can
only be overcome if we find a narrative we all can comfortably enact.)

-- 
Ricardo


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2024-02-06 21:22 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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

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