git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: ZheNing Hu <adlternative@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Git List <git@vger.kernel.org>,
	Raxel Gutierrez <raxelgutierrez09@gmail.com>,
	mricon@kernel.org, patchwork@lists.ozlabs.org,
	Taylor Blau <me@ttaylorr.com>,
	Emily Shaffer <emilyshaffer@google.com>
Subject: Re: Pain points in Git's patch flow
Date: Sun, 2 May 2021 13:35:56 +0800	[thread overview]
Message-ID: <CAOLTT8Sr8hMe7jOaBNb10szbw219HP+FB439jgZu-xua7K9Xug@mail.gmail.com> (raw)
In-Reply-To: <xmqqfszqko0k.fsf@gitster.g>

Haaaa, everyone, I am this example :)
Sorry I haven't checked these mails cc to me for a long time.

Junio C Hamano <gitster@pobox.com> 于2021年4月17日周六 上午3:50写道:
>
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
> >  3. Do you think patchwork goes in a direction that is likely to help
> >     with these?
>
> So here is a real-life example.
>
> Let's say somebody is looking at a "gentle ping" [*1*]
>
> znh> The patch seems to have fallen into the crack.
> zhn> Jeff and Junio, willing to help?
>
> How would we figure out what happened to the patch today without
> visiting patchwork would be:
>
>  1. Visit the message at lore.kernel.org/git/ [*1*]
>
>  2. Notice that it is a response to a message, and click the link to
>     be taken to [*2*]
>
>  3. Notice that nobody commented on the patch.
>
>  4. Type "f:zhening ref-filter" to the search box and search, with
>     suspicion that this was an updated version of something.
>
>  5. Click one of them in the result [*3*]
>
>  6. This time, we can tell that this seemed to have had two earlier
>     iterations, and after reading the discussion through, the last
>     one changed the course in a major way.  Not just a new helper
>     introduced in the earlier rounds has gone away, but an existing
>     helper got removed.
>
>  7. All comments in the discussion for the earlier two rounds can be
>     read as supporting the new direction the latest round takes.
>
>  8. The fact remains that even if the direction has been endorsed
>     (see 7. above) nobody took a look at the implementation for the
>     latest round.
>
>  9. Make the final verdict.
>
> I use my newsreader to do pretty much the equivalent of the above
> without hitting https://lore.kernel.org/git/ but the above is
> written to use the web interface, in order to make it reproducible
> more easily by anybody on the list.
>
> Now, how can patchwork improve the above reviewer experience, out
> of the box and possibly with new helpe rools around it?
>
> I can see #3 would immediately become obvious, and I hope #4-#5
> would become unnecessary.
>

Here are my thoughts:

For the reviewers like Junio, after missing a new patch iteration, need to
review the past history to find the correct patch and related comments
from other reviewers. Just like I once read a github blog saying that
"patch" is also a special object in git. I would like to have a "new" tool
 which can link multiple related patches and comments.

1. Coder need Reviewers' help.
2. This new tool will obtained multiple different patches contents automatically
or coder provided those pathes versions links.
3. This tool will analyze the differences between multiple patches
versions, get all
the reviewers comments and coder comments related to the "patch stream",
organize it into "patch graph".
4. The tool will notify the reviewer(by email or something else) and
show the links
and patch graph or patch range-diff. It can visualize the entire patch process,
 It’s best that comments from different people can be displayed on one page.

In order to be more accurate, I made a picture [*1*].

Using this new tool, reviewers can choose to see or not see the range-diff
and diff in multiple different patch versions, Instead of the range-diff
automatically sent by GGG. When my second patch processing was greatly
changed from the previous one, I have to rebuild a new branch and create a new
PR, this is my pain point.

Thanks!
--
ZheNing Hu

> Anything else?
>
> At steps #6 and #7, there is human judgment involved that may not be
> automatable, but would there be some mechanism to make it easy to
> help these steps if the user visits patchwork (instead of staying
> in my newsreader or web interface to the lore archive)?
>
> I am of course not expecting to automate step #9 ;-)  It would be
> nice though.
>
> Thanks.
>
>
> [References]
>
> *1* https://lore.kernel.org/git/CAOLTT8Tis5Yjg8UR0c-i0BnqiFQvLXvDgxUQJ-WcP6jjQPu9cQ@mail.gmail.com/
>
> *2* https://lore.kernel.org/git/pull.928.git.1617975348494.gitgitgadget@gmail.com/
>
> *3* https://lore.kernel.org/git/pull.927.v2.git.1617809209164.gitgitgadget@gmail.com/

*1* https://github.com/adlternative/git/blob/pic/git-patch-pain-point-solve-idea.png

  parent reply	other threads:[~2021-05-02  5:36 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-14  6:13 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 [this message]
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=CAOLTT8Sr8hMe7jOaBNb10szbw219HP+FB439jgZu-xua7K9Xug@mail.gmail.com \
    --to=adlternative@gmail.com \
    --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 \
    --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).