Re: Pain points in Git's patch flow

> Hi there,
> 
> I'm not a regular contributor but I have started to subscribe to the
> Git's Mailing List recently.  So I thought it might be worth sharing my
> personal view on this.
> 
> After writting all the below, I do realize that I have written quite a
> rant, some of which I think some might consider to be off topic.  For
> that, I do want to appologize before hand.

>  Tue, Apr 13, 2021 at 11:13:26PM -0700, Jonathan Nieder wrote:
> > Hi,
> > 
> ...
> > 
> > Those four are important in my everyday life.  Questions:
> > 
> >  1. What pain points in the patch flow for git.git are important to
> >     you?
> 
> There are several points I want to highlight:
> 
> 1. Issue about reading the Mailing List:
> 
> - Subscribing to Git's Mailing List is not trivial:
>   It takes a lot of time to setup the email subscription.  I remember
>   having to google through a few documents to get my subscription
>   working.
> 
> - And even after having subscribed, I was bombarded with a set
>   of spam emails that was sent to the mailing list address.  These spams
>   range anywhere from absurd to disguising themselves as legitimate
>   users trying to contact you about a new shiny tech product.

> 2. Issue about joining the conversation in the Maling List:
> 
> - Setting up email client to reply to the Mailing List was definitely
>   not trivial.  It's not trivial to send a reply without subscribing to
>   the ML(i.e. using a Header provided from one of the archive).
>   The list does not accept HTML emails, which many clients
>   use as default format.  Getting the formatting to work for line
>   wrapping is also a challenge depends on the client that you use.

> 3. Isssue with archive:
> 
> - I don't find the ML archive trivial for new comers.  It took me a bit
>   of time to realize: 'Oh if I scroll to bottom and find the "Thread 
>   overview" then I can navigate a mailing thread a lot easier'.

> - The lack of labeling / categorization that I can filter while browsing
>   through the archive make the 'browse' experience to be quite
>   unpleasant.  Search is one way to do it, but a new comers would not be
>   knowledgable enough to craft search query to get the archive view just
>   right.  Perhaps a way to provide a curate set of categories would be
>   nice.

> - Lost track of issues / discussion:
>   A quick example would be me searching for Git's zstd support
>   recently with 
> 
>   > https://lore.kernel.org/git/?q=zstandard 
> 
>   and got next to no relevant result.  However if I were to query
> 
>   > 'https://lore.kernel.org/git/?q=zstd'
> 
>   then a very relevant thread from Peff appeared.  I think this could be
>   avoided if the search in ML archive do more than just matching exact
>   text.

> 4. Lack of way to run test suite / CI:
> 
>   It would be nice if we can discuss patches while having CI result as
>   part of the conversation.  Right now mostly I see that we have to
>   manually running benchmarks/tests and share the paste the results.
> 
>   But for folks who don't have a dev environment ready at hand (new
>   comers, during travel with only phone access), it would be nice to
>   have a way to run tests without a dev environment.

>   This was mostly solved in the context of works spent on Github's
>   Action Workflow.  But if we are discussing about pure patch flow, this
>   is a miss.
> 
> >  2. What tricks do you use to get by with those existing pain points?
> 
> For (1):
> - I had to invested a lot of time into setting up a set of Gmail search
>   filter.  Move mails with topics that Im interested in into a special
>   tag while the rest into archive.  Regularly check if anything
>   interesting went to archive by accident.
> 
> For (2):
> - I had to setup Mutt + Tmux to have a compatible experience sending
>   replies like this one.