June 2, 2022 4:00 AM, "Ricardo Wurmus" <rek...@elephly.net> wrote:
> zimoun <zimon.touto...@gmail.com> writes: > >> Ah sorry, I overcomplicate the discussion. :-) > > Hah, no worries! It’s worth discussing this before we implement a > workflow that ends up being *more* confusing than the status quo. > >> To me, it could be nice to have a tiny script (or Guix extension or >> subcommand), maybe in etc/ which simplifies the workflow; something >> similar to ’etc/committer.scm’. >> >> The workflow would be: >> >> $ edit code >> $ git commit >> $ etc/mentoring.scm >> >> where etc/mentoring would generate the patch(es), add X-Debbugs-CC and >> send; assuming a correct ~/.gitconfig. And maybe this script could >> provide a simple hint for configuring git-send-email. >> >> Even, we could imagine that this tiny script would hint the user to run >> “guix lint” or “guix style” before pressing yes at the send step. > > All good ideas, though I think setting up “git send-email” is a pretty > big problem for many people — myself included! Would be nice if that > could be simplified, too. I always use this website to remind myself how to use git send-email: https://git-send-email.io/ We could out that information in the guix manual or link to it. :) > >> From my experience, the most confusing is the “wait from Debbugs ID” >> part, i.e., check your inbox or spam. And I do not know how it could be >> simplified. > > Yes, on top of that comes the gray-listing, which increases the waiting > time. > > Perhaps… we shouldn’t use Debbugs directly. I have a couple of > annoyances with Debbugs, including the fact that we cannot configure the > contents of the emails it sends out. Maybe it is time to implement a > friendlier email-based frontend… > > -- > Ricardo
