Re: Our cumbersome mailing list workflow

[Stefan Beller <sbeller@google.com>]

On Sun, Nov 30, 2014 at 6:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> It seems like a few desirable features are being talked about here, and
>> summarizing the discussion as "centralized" vs "decentralized" is too
>> simplistic. What is really important?
>>
>> 1. Convenient and efficient, including for newcomers
>> 2. Usable while offline
>> 3. Usable in pure-text mode
>> 4. Decentralized
>>
>> Something else?
>

So when I started overtaking the ref log series by Ronnie,
Ronnies main concern was missing reviewers time. So my idea was to
make it as accessible as possible, so the reviewing party can use their
time best. However here are a few points, I want to mention:

 * Having send emails as well as uploaded it to Gerrit, I either needed
   a ChangeId (Gerrit strictly requires them to track inter-patch
diffs), and the
   mailing list here strictly avoids them, so I was told.
   Ok, that's my problem as I wasn't following the actual procedure of the
   Git development model (mailing list only).
 * That's why I stopped uploads to Gerrit, so I do not need to care about the
   ChangeIds any more. I am not sure if that improved the quality of my patches
   though.
 * I seem to not have found the right workflow with the mailing list yet, as I
   personally find copying around the inter-patch changelog very inconvenient.
   Most of the regulars here just need fewer iterations, so I can understand,
   that you find it less annoying. Hopefully I'll also get used to the
nit-picky things
   and will require less review iterations in the future.
   How are non-regulars/newcomers, who supposingly need more iterations on
   a patch,  supposed to handle the inter patch change log conveniently?
   I tried to keep the inter patch changelog be part of the commit message and
   then just before sending the email, I'd move it the non-permanent section of
   the email.
 * Editing patches as text files is hard/annoying. I have setup git send-email,
   and that works awesome, as I'd only need one command to send off a series.
   Having a step in between makes it more error-prone. So I do git format-patch
   and then inject the inter patch change log, check to remove ChangeId and then
   use git send-email. And at that final manual step I realized I am
far from being
   perfect, so sometimes patches arrive on the mailing list, which are
sub quality
   in the sense, that there are leftovers, i.e. a ChangeId
 * A possible feature, which just comes to my mind:
   Would it make sense for format-patch to not just show the diff
stats, but also
   include, on which branch it applies? In git.git this is usually the
origin/master
   branch, but dealing with patch series, building on top of each other that may
   be a good feature to have.

>
> When I had to view a large-ish series by Ronnie on Gerrit, it was
> fairly painful.  The interaction on an individual patch might be
> more convenient and efficient using a system like Gerrit than via
> e-mailed patch with reply messages, but as a vehicle to review a
> large series and see how the whole thing fits together, I did not
> find pages that made it usable (I am avoiding to say "I found it
> unusable", as that impression may be purely from that I couldn't
> find a more suitable pages that showed the same information in more
> usable form, i.e. user inexperience).

So you're liking the email workflow more. How do you do the final
formatting of an email, such as including the inter patch diff?


>
> Speaking of the "whole picture", I am hesitant to see us pushed into
> the "here is a central system (or here are federated systems) to
> handle only the patch reviews" direction; our changes result after
> discussing unrelated features, wishes, or bugs that happen outside
> of any specific patches with enough frequency, and that is why I
> prefer "everything in one place" aspect of the development based on
> the mailing list.  That is not to say that the "one place" has
> forever to be the mailing list, though.  But the tooling around an
> e-mail based workflow (e.g. marking threads as "worth revisiting"
> for later inspection, saving chosen messages into a mailbox and
> running "git am" on it) is already something I am used to.  Whatever
> system we might end up migrating to, the convenience it offers has
> to beat the convenience of existing workflow to be worth switching
> to, at least to me as a reviewer/contributor.

I do like the way as well to just mark emails unread when I need
to work on them later.

>
> As the maintainer, I am not worried too much.  As long as the
> mechanism can (1) reach "here is a series that is accepted by
> reviewers whose opinions are trusted" efficiently, and (2) allow
> me to queue the result without mistakes, I can go along with
> anything reasonable.
>