Re: Our cumbersome mailing list workflow

Torsten Bögershausen [off-list ref] wrote:

On 2014-11-25 01.28, Michael Haggerty wrote:

quoted

  * Or I save the emails to a temporary directory (awkward because, Oh
Horror, I use Thunderbird and not mutt as email client), hope that I've
guessed the right place to apply them, run "git am", and later try to
remember to clean up the temporary directory.

Is there a "mutt howto" somewhere?

Not that I'm aware of, but Documentation/email-clients.txt in
the Linux kernel has some short notes...

My muttrc has had the following since my early days as a git user:

  macro index A ":unset pipe_decode\n|git am -3\n:set pipe_decode\n"
  macro pager A ":unset pipe_decode\n|git am -3\n:set pipe_decode\n"

(Hit Shift-A while viewing/selecting a message to apply a patch,
 it requires you run mutt in your project working directory, though).

Perhaps there can be a similar document or reference to it in our
Documentation/

In short:
We can ask every contributor, if the patch send to the mailing list
is available on a public Git-repo, and what the branch name is,
like _V2.. Does this makes sense ?

Not unreasonable.  I hope that won't give folks an excuse to refuse
to mail patches, though.  Some folks read email offline and can't
fetch repos until they're online again.

I like Gerrit as well.
But it is less efficient to use, a WEB browser is slower (often), and
you need to use the mouse...

IMNSHO, development of non-graphical software should never depend on
graphical software.  Also, I guess there is no way to comment on Gerrit
via email (without registration/logins?).

Lately, I've been trying to think of ways to make collaboration less
centralized.  Moving to more centralized collaboration tools is a step
back for decentralized VCS.

But there is another thing:
Once a patch is send out, I would ask the sender to wait and collect comments
at least 24 hours before sending a V2.
We all living in different time zones, so please let the world spin once.

My feeling is that a patch > 5 commits should have
a waiting time > 5 days, otherwise I start reviewing V1, then V2 comes,
then V3 before I am finished with V1. That is not ideal.

What does it cost to push your branch to a public repo and
include that information in the email ?

And how feasable/nice/useful is it to ask contributers for a wait
time between re-rolling ?

All that sounds good.