Hi Simon, Saku Thank you for your answers.
First, I should have slept on my email instead of sending it right away. I was still dealing with the frustration of having made a fool of myself with debbugs, which compounded with wrestling earlier with golang build system. My tone was unnecessarily harsh, please accept my apologies for that. I'd like to be part of the solution, so Saku, I'd like to help write the putative scripts you talk about. The main difficulty I see is that they need to be configured to be able to send and receive email on the user's behalf. I have some more patches to send over, I'll use that as an excuse to see what I can come up with. Second, I don't know what the general feeling is here towards debbugs, but if moving away from it is something that may happen, my suggestion is not to use anything with Pull Requests, as Simon you seem to have understood. I worded my suggestion poorly. What I had in mind was a (semi-)public-writable repo: code is pushed by developers, pulled and reviewed by maintainers, and if satisfactory, rebased on to master. If communication about the patch is needed, an email thread can be started on the mailing list, CCing the commit author(s) whose email address is known from the commits. A bash one liner starting with git log ... | sed ... can create the email automatically from the proposed branch. There is no need for any active code on the server, just SSH access or maybe public git:// access, and a place to store the repos. See https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/system.scm?ref_type=heads#L526 the os/git function for an example on how to set that up on a guix server. See https://the-dam.org/docs/tutorials/git-hosting.html for how to set it up and https://the-dam.org/docs/tutorials/private-git.html for how to create repos once it is set up. Details need to be ironed out, such as whether to make it world-writable or to have a vetting process, whether to have a public-writable repo segregated from the official one, etc. but I think a reasonable configuration can be found. It seems simpler than git email with or without debbugs, for both maintainers and reviewers, but I'll admit I only have experience working with small teams, and not running a large and successful open source project, so I can't be very assertive there. Lastly, I think the lack of reviewers stems from the lack of contributors. I for one feel like I could give good reviews on trivial patches like new packages and package updates. Just check the repo is the official one, check the licence is good, and check that it, and its descendents, builds. I would gladly review a few packages a week, if I did not dread interacting with git email. Again, not insurmontable, but friction is a powerful thing. If we could onboard contributors more easily, we would have a larger pool of maintainers to pick from. Guix is freaking awesome, but very hard to pick up. It took me a few years to get up to speed. Anyway, thanks for the great software and for the time and guidance y'all give on help-guix and here. Sorry for the ranty email. Cheers, Edouard. Simon Tournier <zimon.touto...@gmail.com> writes: > Hi Edouard, > > It is very important to speak up, although that makes me sad to read > such poor feedback experience. > > Well, the friction is about Debbugs. Maybe I repeat myself: Debbugs is > initially thought to be a bug tracker system and not a patch track system. > > Do not take me wrong, I am not trying to convince you. Instead, I am > just trying to explain that email workflow is not so much different and > the main annoyances you point come from Debbugs and not emails, > somehow. :-) > > On Thu, 14 Sep 2023 at 10:51, Edouard Klein <e...@rdklein.fr> wrote: > >> Before anybody tries to explain to me that git send-email is easier than >> I think, what you have to beat is: > > Well, the complete workflow you have in mind is: > > 1. $ git remote add guix-patches WHATEVER #only once > 2. $ git push -u guix-patches master:some-unique-name > 3. … send a Pull Request … #only once > > Instead, the email workflow somehow reads: > > a. … send an Email to guix-patc...@gnu.org #only once > b. $ git config sendemail.to 12...@debbugs.gnu.org #only once > c. $ git send-email --base=auto -v <N> origin > > and the order is flipped: > > a == 3 #only once > b == 1 #only once > c == 2 > > Yeah, the order appears awkward. But that’s because of Debbugs; else it > would not be very different. > > The advantage is that contributing does not require from you to have a > public Git repository, it requires from you only an email address. > > The drawback (plural!), bah you already know them. :-) > > Again, thank you for your feedback. > > Cheers, > simon
