Re: Our cumbersome mailing list workflow

From: Philip Oakley <philipoakley@iee.org>
Date: Dec 3, 2014, 23:57 UTC
Message-ID: <221286D608764D5EA342E08097333279@PhilipOakley>
In-Reply-To: <5473CD28.5020405@alum.mit.edu>

From: "Michael Haggerty" <mhagger@alum.mit.edu>
Sent: Tuesday, November 25, 2014 12:28 AM

Show 13 quoted lines

> On 11/21/2014 07:00 PM, Junio C Hamano wrote:
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>
>>> I don't think that those iterations changed anything substantial 
>>> that
>>> overlaps with my version, but TBH it's such a pain in the ass 
>>> working
>>> with patches in email that I don't think I'll go to the effort of
>>> checking for sure unless somebody shows interest in actually using 
>>> my
>>> version.
>>>
>>> Sorry for being grumpy today :-(

[..]

Show 36 quoted lines

> Let me list the aspects of our mailing list workflow that I find
> cumbersome as a contributor and reviewer:
>
> * Submitting patches to the mailing list is an ordeal of configuring
> format-patch and send-email and getting everything just right, using
> instructions that depend on the local environment. We saw that hardly
> any GSoC applicants were able to get it right on their first attempt.
> Submitting a patch series should be as simple as "git push".
>
> * Once patches are submitted, there is no assurance that you (Junio)
> will apply them to your tree at the same point that the submitter
> developed and tested them.
>
> * The branch name that you choose for a patch series is not easily
> derivable from the patches as they appeared in the mailing list. 
> Trying
> to figure out whether/where the patches exist in your tree is a 
> largely
> manual task. The reverse mapping, from in-tree commit to the email 
> where
> it was proposed, is even more difficult to infer.
>
> * Your tree has no indication of which version of a patch series (v1,
> v2, etc) is currently applied.
>
> The previous three points combine to make it awkward to get patches 
> into
> my local repository to review or test. There are two alternatives, 
> both
> cumbersome and imprecise:
>
>  * I do "git fetch gitster", then try to figure out whether the branch
> I'm interested in is present, what its name is, and whether the 
> version
> in your tree is the latest version, then "git checkout xy/foobar".
>

I had a thought about the issue of version labeling and of keeping the old patch series hanging about during development that I felt was worth recording.

My thought was that while the cover letter and series version number are currently stripped out from the start of the series, they could be added back as a supplemental commit at the end of the series (an --allow-empty commit). This could contain all of the patch subject lines and their post '---' notes as appropriate.

Thus the series branch would appear to have an extra commit (compared to the current process) after the original tip's possible merge into say pu.

When subsequent series are sent to the list, the new supplemental commit would be a 'merge', with its second parent being the old series, thus the old series is not lost until the branch is deleted, and the existing merge pattern is retained.

Clearly if this would need some additional coding as it's not suitable as a manual process, but it could be just as automatic as the current process while providing that little bit of additional visibility.

Below, I've tried to set out how the commit graph might look (oldest to the left). Hopefully my MUA won't ruin it. The first patch series branches at A, and is merged at D, with the supplemental commit labeled with v1z.

When the new series arrives, and pu is rewound, we have the new series applied from G (which in reality may not be linked directly from A), and merged back at K. However the new v2z supplemental commit is now the po/patches branch head, and is also a merge back to v1z.

patch series 1 (cover letter z)
- A - B - C - D - E - F   <- pu
   \        /
    v1a-v1b--v1z     <-po/patches

patch series 2
- A - G - H - I - J - K     <- pu (note re-wound)
  |        \         /            (merge D lost)
   \       v2a-v2b-v2c--v2z    <-po/patches
    \                  /
    v1a-v1b--v1z - - -.

The key idea here is to use the existing branching model, but then to add the cover letter and other details at the end, rather than the beginning as might have been expected from the email transmit sequence.

Philip