Re: Our cumbersome mailing list workflow

On 14-11-28 09:31 AM, Michael Haggerty wrote:

On 11/27/2014 06:46 PM, Torsten Bögershausen wrote:

quoted

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

quoted

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.

quoted

quoted

[...]
  * 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.

quoted

quoted

* 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.

A bot could subscribe to the list and create branches in a public repo.
(This idea feels familiar -- didn't somebody attempt this already?)

Integrate the bot into the list manager, and every PATCH email sent through
the list could have the patch's URL (maybe in the footer, or as an X- header).

Could this make a decent GSoC project?

		M.