On Mon, 10 Mar 2025 11:37:29 +0100 Simon Tournier <zimon.touto...@gmail.com> wrote:
> Hi Denis, all, Hi, > That’s said, we must recognize that sending patches by emails is not > smooth at all. Indeed. The configuration (smtp settings, or learning how to import patches in mail clients before sending them, etc) is probably too complex for most people. > 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? My question is more "what is the way that can get us there with the least amount of work and that doesn't make the whole process less efficient in the long run?". Alternate proposal: =================== > 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. Right now it seems a bit like having the choice between the Cholera and the Plague, both with really bad aspects, but that are very different, and having a difficult choice between both. There could also be human bias at play here in case where some people probably can't stand the current problem anymore (for good reasons) and would probably like to exchange it as fast as possible for another issue, but while it makes sense in the short run, in the longer run it could be problematic because the trip is one-way only. Having something that mix good aspect of both models looks viable though. For instance an extremely basic workflow that would probably be better than both the current situation and a full-forge workflow would be for a contributor to open an account on a forge vetted by Guix at first (Codeberg for instance), then to send a link that work with "git fetch" to review, by email, to the guix-patches mailing list. Then it would be relatively easy for a reviewer to integrate the patches in a mail client with git fetch and git-imap-send and send both the patches and the comments at the same time to the mailing list. I guess that people using Emacs would also find it relatively easy to open a patch with emacsclient -n $(git format-patch -1) or some other way, and copy-paste it in an email for commenting it, and send them verbatim with git-send-email with the right --in-reply-to. The risk here is to have duplicated patches being sent by 2 different reviewers, but not duplicated threads as the contributor would send the first mail, but that issue is probably less problematic than abandoning the mail workflow completely. Also note that patches carry their own git hash, so if people are inclined, they could also find ways to remove duplicates, though even if nobody does that it's probably fine. Another issue is that we'd probably need to tell contributors not to expect reviews within the forge. It could be told inside the Guix manual. And at the end of the day, if contributors don't understand that, it will probably not increase the maintainers work anyway. And the contributors that do understand all that would get their patches reviewed, so for a contributor, it's probably order of magnitude better to have to learn about all that than not to get your patch reviewed at all, especially if people do know how bad it was before (this should be put in the manual as well along with the explanation on the workflow). And if why we don't review patches within a forge needs to be repeated again and again, because contributors complain, then anybody could reply and explain, not just the reviewers, or send a link, or at worse not reply at all to emails like that. Personally I've also been in the contributor situation described above for patches for programs maintained by Debian, where I had to learn to ping the maintainers though a bug report instead of just sending a pull request, and that took a long time to understand, but at the end the patch was reviewed so I was really happy. So basically as a contributor I'd probably do anything it takes as long as it respects my freedom to get things reviewed, even going through a forge, going to nearby events, running special tools, participating in this discussion about the GCD 002, etc. As a maintainer or someone that reviews and accept patches however, I'd expect to be able to be able to use tools that are up to the task or to make my own from well known reusable components, and in the long run to offload work as much as possible on the contributors for seasoned contributors, and to still teach new contributors to some extent, a bit at a time, or to have contributors teach each other (in some events etc). The Linux case ============== > 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. What I wonder here is if there are ways to simplify the problem as well in order not to have to do too much work. Many years ago, when there was already git, the Q/A in Linux was the contributors and users in most cases as it wasn't really feasible to test a wide variety of hardware automatically. Many of the tools used are relatively standard and can work with other projects as well (git, mailing lists, etc). Only few are specific to C and/or made for Linux like scripts/checkpatch.pl. And the main tool is probably the whole process behind the contribution and / or review and integration of patches which can also be copied / adapted. Also contributors are supposed not to mess up certain very basic steps like to really use ./scripts/checkpatch.pl, to have signed-off-by probably to make sure the patch does apply, etc. And they get reminded or ignored if they don't follows these rules. I'll reply to the rest in another email as mixing the big picture and very specific technical details looks a bit strange. Denis.
pgpPZurGUH_nK.pgp
Description: OpenPGP digital signature
