Maxim Cournoyer <maxim.courno...@gmail.com> 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. I’m no stranger to clunky or quirky interfaces. I put up with them because they unlock workflows and features or flexibility that would otherwise be unattainable. Emacs and Guix are great examples of quirky interfaces that brim with flexibility. I just think that Debbugs doesn’t make the cut. 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. -- Ricardo