Re: Adopt a patch!

[Thomas Danckaert <post@thomasdanckaert.be>]

From: Ricardo Wurmus <rekado@elephly.net>
Subject: Re: Adopt a patch!
Date: Thu, 21 Sep 2017 22:31:29 +0200

>>>> It is not only the work load, but also the work-flow […] This means
>>>> switching forth and back between mail, shell, and browser.
>>> […]
>>>> Compare it with an integrated workflow on e.g. Gitlab or github […]
>>>
>>> How does even more reliance on a browser help here?  Surely, we can
>>> automate more things without imposing a web browser-based workflow to
>>> everyone.
>>
>> +1. I don think the glossy interfaces of Github & co. add much to the
>> table in terms of automation. If you want to test the software, you
>> still have to checkout a local copy of it anyway (i.e., leave the
>> browser).
> 
> FWIW, I didn’t mean to claim that there are no problems with the
> email-based workflow.  I just think that we should improve upon it with
> deliberation instead of jumping to the conclusion that Gitlab or Github
> would be better.

I don't mind the e-mail-based workflow in principle, and find it has
some advantages, but there are a few practical issues.  I'll list my
frustrations, maybe there are concrete solutions for some of them:

 - I find that saving a long patch series from a bunch of e-mails, and
   applying them all to a local git checkout is tedious, with a lot of
   potential to miss a patch, apply a wrong one, or otherwise screw up
   (not to mention patches occasionally get mangled somewhere in the
   e-mail pipeline, so git won't apply them).  Also, sometimes patches
   are in the message body, at other times they are attachments,
   ... It *is* a lot of error-prone manual work, compared to just
   fetching a branch with git.  I think this is where the “glossy
   interfaces of Github & co.” do have an advantage.

   Perhaps there are better ways to deal with this, though... Am I
   missing some tricks to easily retrieve a bunch of patches from
   e-mails, and apply them?  Maybe a tutorial by someone who finds the
   current workflow comfortable, could already help.

The other issue is that, in my opinion, the only user-friendly way to
interact with debbugs, is using emacs + debbugs-gnu, once you are
familiar with both.  I think that's a really high barrier.

- I briefly subscribed to the guix-patches mailing list, but found the
  volume of e-mail much too high.

- That leaves debbugs.  I find the web interface quite terrible, it's
   just walls of text you have to find your way through. For example,
   Github's “issues” are much more readable (and you can interact with
   them via e-mail, too).

- The debbugs emacs interface is quite ok (at least there's a threaded
  conversation view), although now you have to learn to use Gnus if
  you want to participate in the conversation.

So I do see the appeal of something like gitlab, but I also wonder how
it could be integrated in the current workflow.  I think it could help
a lot if debbugs took some ideas from github/gitlab, but I don't think
debbugs is actively worked on?

Thomas