Hi Denis, all,
I agree with some points you list here. For instance, using Codeberg,
somehow we do not apply the dogfooding principle of “user-autonomy”; as
I pointed [1] very early in the discussion. :-)
Moreover, it also raises practical considerations as the backup [2] of
all the discussions that would happen in Codeberg.
Yeah, I’m happy with my setup and I shared [3] several times how Emacs +
Notmuch + Org-mode is really nice for me. And I also engaged [4] how
public-inbox can help.
That’s said, we must recognize that sending patches by emails is not
smooth at all.
On Fri, 07 Mar 2025 at 16:39, Denis 'GNUtoo' Carikli
<gnu...@cyberdimension.org> wrote:
> As I understand it, we have problems to solve, the main one right now
> being to lower the time of reviewing patches, and so whatever we do, we
> probably need to start with our needs first, and try to find tools (in
> the general sense, not necessarily computer programs) that can easily be
> adapted to suit our needs and their evolution as well.
If you want to have an idea about the bottleneck, I encourage to try to
apply all the patches sent just one specific day and build them – no
review! Only one day, you just apply to your local Git repository all
the patches sent to guix-patches mailing list.
Some patches are poorly formatted or some patches do not apply because
the local tree isn’t in an adequate state – e.g., you must checkout a
specific commit and then apply.
All that is gone with PR. You directly fetch a remote Git-branch.
Obviously, PR raises many other annoyances. :-)
An example, just on past Friday, I’ve spent more time in fighting with
Git in order to apply than to effectively review.
Well, there is so many trivial details that you need to check…
Obviously, it’s too easy to miss one; especially when your attention is
retained by “damned! why does it not apply?!?”.
Look, somehow the patch had been sent in a way, so the field From reads:
"King, Spencer via Guix-patches" via <guix-patc...@gnu.org>
but the patch itself (as an attachment) contains the field From:
From: Spencer King <spencer.k...@wustl.edu>
Therefore, I’ve missed it when applying; end result: the commit
c8bde3c6725be4eb0743a153a3cf8de453d9e448 reads:
Author: King, Spencer via Guix-patches via <guix-patc...@gnu.org>
For sure, I’m not the only one that did this kind of mistake:
--8<---------------cut here---------------start------------->8---
$ git log --format="%ae" | grep guix-patches | wc -l
346
--8<---------------cut here---------------end--------------->8---
That’s one example over many others.
Yes, this can be fixed with tooling. But that’s the wrong frame for an
answer, IMHO. The question is: who commits in maintaining such tools?
> In practice some people I talked to (which includes a committer who
> reviews patches) also clearly indicate that it will (depending on who
> you ask) not enable us to solve the issues we have, or make things much
> worse as that would be less productive with a forge workflow.
Yes, I agree. And I say it publicly: I’m very doubtful that replacing
one workflow by another will help with the core of the bottleneck.
We will have the same issue: Too much patches, not enough reviewers.
This is an invariant with all the Free Software project.
The question is about the scale. Do we speak about 100 patches and 1
reviewer? Or about 1000 patches and 10 reviewers? Same bottleneck but
10 times more patches merged.
( Aside it raises another question that I’m not comfortable because I
do not think that scaling up Guix is a worth direction. Today, so
many Guix operations are so slow that each time I use APT or Docker
or Conda or else, I ask to myself “Why do I use Guix already?” and I
repeat to myself several times in a row “Guix helps me about
Reproducible Research, keep going!” )
Somehow, that’s the expectation with this move of workflow: Smooth the
review to have more people committed in. If we do not act now about the
workflow for reviewing, the project is going to scale down in a bad way,
IMHO.
That’s why it’s a difficult decision.
> If we look at big projects like Linux, they have faced a similar issue
> in the past and as I understand they solved it by using more adapted
> tools and processes and they even ended up making their own software
> tools (git, checkpatch.pl, etc) for the critical parts,
This is partly my opinion too. That’s why I raised public-inbox couple
of times in the past. However, as I pointed above, it’s still not very
smooth. Why?
Because Guix does not have the same profile. I let aside the
Contributors side – it’s a question but not really one when speaking
about Reviewing :-) – and focus on Reviewers.
1. Linux is large enough to have full-time paid people to work on. For
instance, you mention Greg KH. To my knowledge, their day job is to
review and apply patches.
In Guix, to my knowledge, no one is paid for that.
2. Because Linux is heavily used by many companies, they have developed
and implemented many tools for CI and all that. Well, it is not the
point; the point is: companies financially support the maintenance of
the infra and of the tools.
In Guix, to my knowledge, we do not fully have this. Or better
worded, we do not have the adequate ratio between the needs and the
capacity to cover such needs, IMHO.
> But we also need to improve the current flavor of the mail workflow we
> use as well I think.
Yes in an ideal world. Sadly, many of us are free-riders here.
Therefore the frame is: Who commits in improving?
> At the end of the day I think that the overall solution proposed, which
> is to find tools that are well maintained by others and more adapted is
> perfectly valid, but I think we should instead adopt tools that work
> with the mail workflow because it scales, like public-inbox, find if we
> can learn things from Linux, etc.
It was my opinion, and it’s more or less still my opinion. :-)
However, look [6] from 2021. What have changed since? The annoyances
about the email workflow isn’t new; it’s around since many years.
IMHO, the frame isn’t what “we should do in this direction of improving
the email workflow“, but the frame appears to me: What have been done?
And more importantly, why this or that has not been collectively fixed?
All in all, as discussed in the last Guix Paris Meetup, I also share
many questions as you. Once we have exposed the bottleneck, the next
step isn’t what we potentially should do but we concretely need to do.
Whatever my opinion about the proposed “Migration Path”, today I have
nothing better to propose than accepting the proposal to implement the
PR workflow in order to smooth the bottleneck. Therefore, I try very
hard to avoid the human bias of resistance to change and instead try to
focus on what I can or cannot live with for my day-to-day collaboration
with Guix.
Cheers,
simon
1: Re: [GCD] Migrating repositories, issues, and patches to Codeberg
Simon Tournier <zimon.touto...@gmail.com>
Thu, 30 Jan 2025 14:13:30 +0100
id:87wmec4f7p....@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2025-01
https://yhetil.org/guix/87wmec4f7p....@gmail.com
2: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Simon Tournier <zimon.touto...@gmail.com>
Thu, 06 Mar 2025 17:36:29 +0100
id:874j066rqq....@gmail.com
https://issues.guix.gnu.org/76503
https://issues.guix.gnu.org/msgid/874j066rqq....@gmail.com
https://yhetil.org/guix/874j066rqq....@gmail.com
3: https://10years.guix.gnu.org/program/#emacs-debbugs-and-public-inbox
4: Mumi, public-inbox and tools
zimoun <zimon.touto...@gmail.com>
Mon, 02 May 2022 20:10:14 +0200
id:87bkwf956h....@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2022-05
https://yhetil.org/guix/87bkwf956h....@gmail.com
5: [bug#76773] [PATCH] gnu: Add julia-polylog.
"King, Spencer via Guix-patches" via <guix-patc...@gnu.org>
Thu, 06 Mar 2025 06:18:41 +0000
id:ch3pr02mb97462a0d8bd64c76eb1956c690...@ch3pr02mb9746.namprd02.prod.outlook.com
https://issues.guix.gnu.org/76773
https://issues.guix.gnu.org/msgid/ch3pr02mb97462a0d8bd64c76eb1956c690...@ch3pr02mb9746.namprd02.prod.outlook.com
https://yhetil.org/guix/ch3pr02mb97462a0d8bd64c76eb1956c690...@ch3pr02mb9746.namprd02.prod.outlook.com
6: Re: Tricking peer review
zimoun <zimon.touto...@gmail.com>
Tue, 19 Oct 2021 16:22:30 +0200
id:86k0i9drh5....@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2021-10
https://yhetil.org/guix/86k0i9drh5....@gmail.com
