From: ZheNing Hu <email@example.com> To: Junio C Hamano <firstname.lastname@example.org> Cc: Jonathan Nieder <email@example.com>, Git List <firstname.lastname@example.org>, Raxel Gutierrez <email@example.com>, firstname.lastname@example.org, email@example.com, Taylor Blau <firstname.lastname@example.org>, Emily Shaffer <email@example.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: <firstname.lastname@example.org> Haaaa, everyone, I am this example :) Sorry I haven't checked these mails cc to me for a long time. Junio C Hamano <email@example.com> 于2021年4月17日周六 上午3:50写道： > > Jonathan Nieder <firstname.lastname@example.org> 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://email@example.com/ > > *3* https://firstname.lastname@example.org/ *1* https://github.com/adlternative/git/blob/pic/git-patch-pain-point-solve-idea.png
next prev 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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).