On 2023-09-03, Ricardo Wurmus wrote: > Maxim Cournoyer writes: > >> In the simplest case, it can be as simple as: >> >> $ ./pre-inst-env guix refresh -u some-package >> [build it, try it, fix if needed] >> $ ./etc/committer.scm >> $ git send-email >> >> Since it's a single patch, there's no jumping through hoops to create >> the original issue, and the auto-configured git will CC teams people >> subscribed to the scope of your change (if there are any). > > Sadly the not-so-simple case is much more annoying. > > I like an email-based workflow, don’t get me wrong. At the same time > I’m really not a fan of Debbugs. It makes simple things more difficult > than they should be (send a cover letter, wait for your mail to pass the > anti-spam measures, remember that you wanted to send a couple of > patches, etc), and no amount of sugar coating (whether that be a > different frontend like Mumi or a hell of a lot of client-side > scripting) can overcome this inherent clunkiness. The only thing clunky about this particular aspect of the workflow described is the fact that the guix community (maintainers?) have decided on a one patch per mail policy with a cover letter, rather than submitting the patches as attachments in the initial mail. Debbugs may have numerous other ugly warts, but that is not really one of them, in my opinion. Changing that one policy (expectation?) would probably remove a significant portion of the friction many people have with patch submissions... That change will likely have have other frictions, but I suspect they would be much easier to adapt to... > If only we can find a suitable baby sieve, I’d be happy to see the > turbid bathwater drained. If Mumi and Debbugs went down the drain to > reveal a new hassle-free web/email hybrid patch workflow I’d be > ecstatic. I cannot complain about wanting the best of both worlds if the cost is not too high. :) For most of my work in Debian, I accept patches via bugs.debian.org (the *original* debbugs instance, primarily email) or salsa.debian.org (a gitlab instance, primarily web)... Sometimes it is a little awkward because specific maintainers prefer one interface over the other, or only pay attention to one or the other... but for the most part I find it allows people to use whatever works best for them... At the end of the day git allows quite a few workflows, and the submitters and committers do not even have to use the entirely same workflow. There is plenty of room to be flexible. I recently learned about and started using: https://git.guix-patches.cbaines.net/git/guix-patches This allows me to pull the latest (usually!) patch submissions and fiddle with and chew on offline... in the same way I might work with most other git-based projects, merging and cherry-picking and doing unmentionable things to those poor patches, all from the comfort of my local machine. It suppliments the email workflow quite nicely, in my opinion. So, on the other end, if there was a central place where people (ideally very open) could push patch submissions, so that people could more easily pull them all at once, that might help alleviate some of the issue from the other direction... The fact that Guix code is largely a single git repository is something I really value, and makes many things much easier... compared to Debian which has largely one git respository per package, which might be hosted on arbitrary servers, or maybe some other VCS, or maybe not even any VCS at all (other than the Debian mirror itself)... live well, vagrant