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