Pain points in Git's patch flow
adlternative at gmail.com
Sun May 2 15:35:56 AEST 2021
Haaaa, everyone, I am this example :)
Sorry I haven't checked these mails cc to me for a long time.
Junio C Hamano <gitster at pobox.com> 于2021年4月17日周六 上午3:50写道：
> Jonathan Nieder <jrnieder at 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.
> 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.
> *1* https://lore.kernel.org/git/CAOLTT8Tis5Yjg8UR0c-i0BnqiFQvLXvDgxUQJ-WcP6jjQPu9cQ@mail.gmail.com/
> *2* https://email@example.com/
> *3* https://firstname.lastname@example.org/
More information about the Patchwork