git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: git@vger.kernel.org, Raxel Gutierrez <raxelgutierrez09@gmail.com>,
	mricon@kernel.org, patchwork@lists.ozlabs.org,
	Junio C Hamano <gitster@pobox.com>, Taylor Blau <me@ttaylorr.com>,
	Emily Shaffer <emilyshaffer@google.com>
Subject: Re: Pain points in Git's patch flow
Date: Mon, 26 Apr 2021 02:04:32 +0000	[thread overview]
Message-ID: <YIYfsMsz0Uz48GaI@camp.crustytoothpaste.net> (raw)
In-Reply-To: <YHaIBvl6Mf7ztJB3@google.com>

[-- Attachment #1: Type: text/plain, Size: 5859 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  parent reply	other threads:[~2021-04-26  2:04 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-14  6:13 Pain points in Git's patch flow Jonathan Nieder
2021-04-14  7:22 ` Bagas Sanjaya
2021-04-14  8:02   ` Junio C Hamano
2021-04-14 21:42     ` Junio C Hamano
2021-04-15  8:49   ` Denton Liu
2021-04-15  6:06 ` Junio C Hamano
2021-04-15 15:45 ` Son Luong Ngoc
2021-04-19  2:57   ` Eric Wong
2021-04-19 13:35     ` Theodore Ts'o
2021-04-21 10:19     ` Ævar Arnfjörð Bjarmason
2021-04-28  7:21       ` Eric Wong
2021-04-28  7:05     ` Eric Wong
2021-04-15 18:25 ` Atharva Raykar
2021-04-16 19:50 ` Junio C Hamano
2021-04-16 20:25   ` Junio C Hamano
2021-05-02  5:35   ` ZheNing Hu
2021-04-18  8:29 ` Sebastian Schuberth
2021-04-18 20:54   ` Ævar Arnfjörð Bjarmason
2021-04-19  2:58     ` Eric Wong
2021-04-19  5:54     ` Sebastian Schuberth
2021-04-19  6:04       ` Sebastian Schuberth
2021-04-19  8:26       ` Ævar Arnfjörð Bjarmason
2021-04-19 19:23         ` Sebastian Schuberth
2021-04-19 22:34           ` Theodore Ts'o
2021-04-20  6:30             ` Sebastian Schuberth
2021-04-20 16:37               ` Theodore Ts'o
2021-04-30 20:45               ` Felipe Contreras
2021-04-20 10:34           ` Ævar Arnfjörð Bjarmason
2021-04-19 19:36       ` Eric Wong
2021-04-19 19:49         ` Sebastian Schuberth
2021-04-19 22:00           ` Konstantin Ryabitsev
2021-05-08  2:10             ` dwh
2021-04-19 21:49       ` Konstantin Ryabitsev
2021-04-19 23:03         ` Stephen Smith
2021-05-08  2:08         ` dwh
2021-05-08  4:41           ` Bagas Sanjaya
2021-04-30 20:58       ` Felipe Contreras
2021-04-21  4:46 ` Daniel Axtens
2021-04-26  2:04 ` brian m. carlson [this message]
2021-04-26 14:24   ` Theodore Ts'o
2021-04-26 14:36   ` Ævar Arnfjörð Bjarmason
2021-04-28  7:59   ` Eric Wong
2021-04-28 22:44     ` brian m. carlson
2021-04-30 20:16     ` Felipe Contreras
2021-04-30 20:35   ` Felipe Contreras
2021-04-30 21:09 ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YIYfsMsz0Uz48GaI@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=me@ttaylorr.com \
    --cc=mricon@kernel.org \
    --cc=patchwork@lists.ozlabs.org \
    --cc=raxelgutierrez09@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).