git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: git@vger.kernel.org
Cc: 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: Pain points in Git's patch flow
Date: Tue, 13 Apr 2021 23:13:26 -0700	[thread overview]
Message-ID: <YHaIBvl6Mf7ztJB3@google.com> (raw)

Hi,

I'd like to introduce Raxel (cc-ed), who is starting an internship
this June with the Git team at Google.

He'll be working on a bit of an experimental project: we want to take
Patchwork[1], which in principle can be a helpful addition to a
mailing list centric workflow[2], and improve it to be something that
people in the Git open source project get day-to-day benefit from.
Raxel's previous successes in making changes to tools to support a
better user experience make me excited for the potential for this
work.

Anyway, yesterday[3] Junio, Taylor, and Emily were discussing how to
encourage more reviews:

 <gitster> this week, i'd be thinking about ways to get topics, that
           are not reviewed sufficiently, reviewed. I can act as the
           last-resort fallback reviewer, but that's not sufficient.
 <ttaylorr> gitster: I share your concern.
 <nasamuffin> gitster: yep, agree, on both counts

That reminded me that it would be useful preparation to collect
descriptions of pain points we are having with our existing patch
flow.  For example:

- As a reviewer, I want to be able to easily find a series that needs
  review.  Using patchwork, I can see some recent patch series; or
  using a hierarchical threaded mail reader, I can find a neglected
  thread or one that seems to be likely to have an interesting
  discussion going on.  But without reading in detail, there is no
  easy way to see whether the series has reached a review, whether
  someone else intends to review it, and what the author believes its
  status to be.

- Relatedly, as a patch author or reviewer, I want to be able to
  easily tell whether a topic has been sufficiently reviewed.  Today,
  the signals for this are implicit: I have to judge consensus, or to
  check the Git repository for whether the patch has been merged, or
  to check the maintainer's latest "What's cooking in git.git"
  message.

- As a potential reviewer or interested user, I want to be able to
  follow all relevant discussion for a patch series, while also
  having the ability to stop following it if the discussion goes on
  too long and starts overwhelming my email inbox.  Today, I can join
  the discussion and then (1) it is hit-or-miss whether the patch
  author ccs me on later iterations of the patch and (2) there is no
  easy way without aggressive email filtering to stop watching it if
  I am cc-ed.

- After having diagnosed an issue to be due to a patch, I want to be
  able to easily find all relevant review discussion.  Today I can
  use the mailing list archive[4] or patchwork to find review
  discussion on the latest version of the series that patch was in,
  but tracing back to previous iterations of that same series can be
  non-trivial.  Moreover, if I'm interested in a particular puzzling
  line of code, finding which iteration introduced it can take a long
  time.

Those four are important in my everyday life.  Questions:

 1. What pain points in the patch flow for git.git are important to
    you?

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

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

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

Thanks,
Jonathan

[1] http://jk.ozlabs.org/projects/patchwork/; you can see an instance
for Git at https://patchwork.kernel.org/project/git/list/
[2] https://kernel-recipes.org/en/2016/talks/patches-carved-into-stone-tablets/,
https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html#_patch_workflow
[3] https://colabti.org/irclogger/irclogger_log/git-devel?date=2021-04-12#l40
[4] https://lore.kernel.org/git/

             reply	other threads:[~2021-04-14  6:14 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-14  6:13 Jonathan Nieder [this message]
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
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=YHaIBvl6Mf7ztJB3@google.com \
    --to=jrnieder@gmail.com \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=mricon@kernel.org \
    --cc=patchwork@lists.ozlabs.org \
    --cc=raxelgutierrez09@gmail.com \
    --subject='Re: Pain points in Git'\''s patch flow' \
    /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

Code repositories for project(s) associated with this 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).