Pain points in Git's patch flow

[brian m. carlson]

On 2021-04-14 at 06:13:26, Jonathan Nieder wrote:
> Those four are important in my everyday life.  Questions:
> 
>  1. What pain points in the patch flow for git.git are important to
>     you?

I realize I'm a bit late here, but I've been thinking about this some
and wanted to chime in.

I have trouble finding all the spots where people have given me review
feedback.  I have patch mails and responses to those mails go to a
particular folder, but I still often find that I'm not quite sure if
I've gotten every piece of feedback in a review.  Sometimes,
embarrassingly, I don't, and then I have to send another reroll.
Regardless, this makes rerolling a series much slower as I have to comb
my mail multiple times.

I find I'm often unsure what to put in the cover letter for a v2 or
subsequent series.  Clearly people don't want the same thing as v1, but
I rarely have useful information other than a summary of changes.

I have tooling to automatically generate the proper range for
range-diffs in cover letters, but that tooling requires some sort of
manual timestamp, which means I need to go search for my previous series
to find the date and generate the range diff, or if I'm in a rush, I
just have to omit it.  This can take some time, having to guess what I
named the cover letter the last time and search for it in a mailbox with
a 6-digit quantity of mails[0].

In general, I have trouble keeping track of the patch mails I've sent.
I do definitely need to refer to them later, but I don't generally keep
them around on my system since they tend to duplicate my repository, so
I end up needing to find them in my mailbox, which as mentioned, is
slow and error prone.

I find that the git-contacts script is often not helpful to find
reviewers.  When I send out a series, it often suggests Peff and Junio.
While both of them are very capable, they are also not capable of
reviewing every series, and in many cases I know full well that one or
the other is not going to be able to give me a good review (for lack of
familiarity with the SHA-256 work, due to having many other things to
review and to do in life, or for other reasons).  It also,
unfortunately, suggests me as a reviewer for many things, which while
flattering, reflects the fact that I've touched a lot of code and not
that I have a deep understanding of most of the codebase, which I do
not.  For areas where I do have relevant insight, such as the signature
code, I'm often not chosen.

I realize a lot of these are not intrinsic to our workflow and can be
solved with tooling, but because I haven't built that tooling, they're
pain points that I experience in our workflow.

>  2. What tricks do you use to get by with those existing pain points?

I've built some tooling around this, including mail filtering, aliases,
and scripting, but it doesn't seem like enough.  I know others have
built really great tooling for themselves, but by the time I notice
these pain points, it's usually the evening and I don't have time
to build tooling and get things sent out as well.  I also don't
especially enjoy building tooling here.

The friction here makes me less likely to send out patches and much
slower to reroll patches than I'd otherwise be.  And I feel like that
means that I practically can only ever send out a series when I have
more time on the weekend, and as a result, I worry that my patches hold
up others in the tree much more often than I'd like.  It also makes
contributing to Git less fun, which is important since overwhelmingly my
patches are sent on my own time.

>  3. Do you think patchwork goes in a direction that is likely to help
>     with these?

I don't think I know enough about it to say.  If it can more clearly
track review feedback and help keep track of patch emails, I think it
would be a major improvement, for me at least.

>  4. What other tools would you like to see that could help?

I think we definitely need a bug tracker.  We extremely frequently lose
bugs and feature requests on the list and people aren't very likely to
search the list.  If we could use the same one as someone else, such as
the kernel, that would be ideal, because it means people are more likely
to already have an account and therefore the friction to report a bug is
lower.  Alternatively, we could use something like debbugs which is
controllable entirely by email and therefore requires no accounts (but
does require someone to occasionally prune reported spam).

I know full well why we don't use a forge-based model and I'm not
recommending that, but I do want to point out that forges solve all of
my pain points, and I do have a much quicker turnaround time on patches
when I'm using a forge.  So ideally we'd have some standard or
recommended tooling, whether built by us or by others (e.g., an open
source project for patch workflows), that addresses these pain points so
that everyone doesn't have to build their own and turnaround time can be
improved.

I have seen replies downthread that some developers really are reticent
to use more common tooling, like web interfaces.  While I do want to
keep our project as accessible as possible to as many people as
possible, I worry that by catering to folks who don't want to adopt this
tooling, we are drastically reducing the number of possible contributors
of all sorts (code authors, documentation writers, bug reporters) by
not doing so and worsening our own experience in many ways.  I do think
we should adopt modern tooling (e.g., web interfaces) provided that it
is usable for people with accessibility needs, even if that makes some
people unhappy.

[0] I don't, as a general rule, delete emails to this list or otherwise.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/patchwork/attachments/20210426/d648faff/attachment.sig>