Re: Our cumbersome mailing list workflow

> On 11/27/2014 06:46 PM, Torsten Bögershausen wrote:
>> On 2014-11-25 01.28, Michael Haggerty wrote:
>> []
>>> 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.
>> Typically everything fits into ~/.gitconfig,
>> which can be carried around on a USB-Stick.
>> Is there any details which I miss, or howtows we can improve ?
> 
> I used to need one setup at work and a different one at home (because of
> how my email was configured), and sometimes had to switch back and forth
> as I carried my notebook around.
> 
>>> [...]
>>>   * 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".
>> There are 12 branches from mh/, so it should be possible to find the name,
>> und run git log gitster/xy/fix_this_bug or so.
>> Even more important, this branch is the "single point of truth", because
>> this branch may be merged eventually, and nothing else.
> 
> I know it's *possible*. The question is whether it could be made easier.
> 
>>> * Following patch series across iterations is also awkward. To compare
>>> two versions, I have to first get both patch series into my repo, which
>>> involves digging through the ML history to find older versions, followed
>>> by the "git am" steps. Often submitters are nice enough to put links to
>>> previous versions of their patch series in their cover letters, but the
>>> links are to a web-based email archive, from which it is even more
>>> awkward to grab and apply patches. So in practice I then go back to my
>>> email client and search my local archive for my copy of the same email
>>> that was referenced in the archive, and apply the patch from there.
>>> Finding comments about old versions of a patch series is nearly as much
>>> work.
>> 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 ?
> 
> That would be helpful, but it would put yet *another* requirement on the
> submitter (to send patch emails *and* push the branch to some accessible
> repository). We regulars could script this pretty easily, but people who
> only contribute occasionally or who are trying to get started will be
> even more overwhelmed.