Re: Guix Days: Patch flow discussion

[Giovanni Biscuolo <g@xelera.eu>]

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

Hello Simon,

first and foremost: I'd like to say a big thank you to all the people
working in the Guix community...

...and apologise if I still cannot do more to help.

Simon Tournier <zimon.toutoune@gmail.com> writes:

[...]

> Well, let me try to quickly summarize my conclusion of the session:
>
>  1. We have a social/organisational problem.
>
>  2. We have some tooling annoyances.
>
>
> The easy first: #2 about tools.  The email workflow is often cited as
> part of the issue.  That’s a false-problem, IMHO.

yes, we (as a community) already had several discussions around the
false-problem named "email worfkow is too hard", I also dared to send a
*very* lenghty analysis comparing the _so_called_ "pull request model" [1] 

Unfortunately I'm pretty sure that _this_ false issue will be cited
again and again and again when discussing about "how to better help Guix
maintainers"

...unless the (info "(guix) Submitting Patches") one day will finally
(briefly) explain why the project is using an email based workflow and
not a "so called PR workflow" (to understand why PR workflow is "so
called" please read [1]) 

But all this discussion on the "email workflow" issue is more useless
when considering the commit authetication mechanism _embedded_ in Guix
since 2020;  I recently studied this blog post:

https://guix.gnu.org/en/blog/2020/securing-updates/

and it states:

--8<---------------cut here---------------start------------->8---

To implement that, we came up with the following mechanism and rule:

1 The repository contains a .guix-authorizations file that lists the
 OpenPGP key fingerprints of authorized committers.

2 A commit is considered authentic if and only if it is signed by one of
 the keys listed in the .  guix-authorizations file of each of its
 parents. This is the authorization invariant.

[...]

The authorization invariant satisfies our needs for Guix. It has one
downside: it prevents pull-request-style workflows. Indeed, merging the
branch of a contributor not listed in .  guix-authorizations would break
the authorization invariant. It’s a good tradeoff for Guix because our
workflow relies on [patches carved into stone tablets] (patch tracker),
but it’s not suitable for every project out there.

--8<---------------cut here---------------end--------------->8---

[patches carved into stone tablets] is a link to:

https://lwn.net/Articles/702177/
«Why kernel development still uses email»
By Jonathan Corbet, October 1, 2016 

an article with another ton of reasons why "all patch management tools
sucks, email just sucks less.

Anyway, since Guix is using the "authorization invariant" since 2020,
the "email workflow" is embedded in Guix :-D

Am I missing something?

> Projects that use PR/MR workflow have the same problem.  For instance,
> Julia [1] has 896 open PR. 

[...]

> I will not speak about the channel ’nonguix’ but it gives another
> clue.

I will not speak about kubernetes, cited in the above cited LWN article,
I will not speak about Gerrit, also cited there...

[...]

> To be clear, the email workflow might add burden on submitter side but I
> am doubtful it is really part of the bottleneck for reviewing and
> pushing submissions.

Email workflow makes the reviewing workflow _extremely_ easy, provided a
good MUA and a _little_ bit of self-discipline following the /easy/
guidance in (info "(guix) Reviewing the Work of Others")

> Although the tools might add some unnecessary friction, the net of the
> issue is IMHO #1: reviewing is just boring and time-consuming.

This is the one and only reason.

[...]

I don't have anything to add, for now.


Happy hacking! Gio'


[1] id:87y1ha9jj6.fsf@xelera.eu aka
    https://yhetil.org/guix/87y1ha9jj6.fsf@xelera.eu/

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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