Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

From: Jeff King <peff@peff.net>
Date: Aug 19, 2016, 15:03 UTC
Message-ID: <20160819150340.725bejnps6474u2e@sigill.intra.peff.net>
In-Reply-To: <alpine.DEB.2.20.1608181430280.4924@virtualbox>

On Thu, Aug 18, 2016 at 02:42:34PM +0200, Johannes Schindelin wrote:

Show 20 quoted lines

> BTW I take this thread as yet another proof that people are unhappy with
> mail list-based review: if you have to build *that much* tooling around it
> (and Peff & Junio certainly have a megaton of advanced and sophisticated
> tooling around it, holy cow!) it is really incorrect to state that the
> mail list-driven approach works for you. It is much closer to the truth to
> say that the mail-list-plus-loads-of-custom-tools-driven approach works
> for you.
> 
> I am really not a fan of this.
> 
> The theory "it's inclusive because everyone has access to mail" falls on
> its face, badly, when even old timers have to build entire infrastructures
> around it just to begin to be able to use it efficiently.
> 
> It reminds me of an old software developer I met long ago, who claimed CVS
> works for him. He had written tens of thousands of lines of shell scripts,
> is what allowed "CVS" to work for him.
> 
> Same here. Old dogs claim the mail list-approach works for them. Nope.
> Doesn't. Else you would not have written all those custom scripts.

I read this over, didn't agree, waited a whole day for perspective, and still just can't agree. So now I'm responding. :)

There is nothing wrong with building tooling around your workflow. If we had a GitHub-based workflow, I'd build tooling around that, too. One of the things I _like_ about a mail-based workflow is how easy it is to build that tooling, and to get it to integrate with other existing tools. It's the major reason I'm resistant to moving development to GitHub. Not only would I have to throw away all of my tools, but I'm not sure I could easily build equivalent ones.

Now, I am perfectly open to the idea that more of the tooling should be standardized, so people do not have to build their own. But the major problem there is that so much of what I've built is about gluing things together for the rest of _my_ tools. I've shared my techniques and scripts for using mutt several times, but they don't do somebody a lick of good if they are using gmail or thunderbird.

So I don't really think I have a megaton of tooling. I just have a little bit of glue to existing tools I was using anyway. And I think that is where the disconnect is. If you are not using mutt already, then it sure seems like a big jump to change your MUA. And I'm sympathetic to that. But I don't think that means that the mailing-list approach is not working for me, as you claim in the last paragraph.

-Peff

PS There _are_ some open questions in our workflow that are not really
   mailing list specific. E.g., the fact that it is hard to see whether
   and if your patch was picked up by Junio, what changes were made,
   tracking multiple versions, etc. I _don't_ have good tooling for
   that, but it's something that could be made generally available, as
   it's unrelated to the MUA. It's also not necessarily specific to
   mailing list development (e.g., a push-based workflow that
   aggressively rebases runs into the same versioning questions).