{"thread":{"id":"64216","subject":"[RFC] How to accellerate the patch flow (or should we?)","startedAt":"2025-09-26T22:24:06Z","lastAt":"2025-10-01T20:00:43Z","messageCount":17,"participants":["Junio C Hamano","Taylor Blau","Kristoffer Haugsbakk","Ben Knoble","Patrick Steinhardt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"527449","messageId":"xmqqldm0am4b.fsf@gitster.g","threadId":"64216","inReplyTo":null,"subject":"[RFC] How to accellerate the patch flow (or should we?)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-09-26T22:24:04Z","receivedAt":"2025-09-26T22:24:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"A typical lifecycle of a patch series sent to the list ought to be\nas follows:\n\n 1. You write a solution, describe the problem and solution in a\n    patch series, send it to the list.\n\n 2. People notice, take interest in, and comment on these patches.\n\n 3. After #2 above, you may find it necessary to produce an updated\n    version.  Go back to #1.\n\n 4. While the above cycle is running, the maintainer may queue it in\n    'seen', for two purposes.  (1) not to lose sight and forget\n    about the change.  (2) to catch potential conflicts and overlaps\n    with other in-flight topics to keep their interaction manageable.\n\n 5. The maintainer notices that the discussion has reached a\n    conclusion that the patch series is in a good shape, and merges\n    it to 'next'.\n\n 6. If a problem is found while the topic is in 'next', the topic\n    may be marked as 'on hold' until an incremental solution to the\n    problem is created.  This step may repeat while the topic is in\n    'next'.  If the problem, which hasn't been noticed before #5\n    happend, turns out to be so severe, the topic may have to be\n    ejected out of 'next' for fresh restart.\n\n 7. If 7 calendar days passes since the topic was merged to 'next'\n    (or any incremental fixes are also added and merged to 'next')\n    without any further finding of more problems, the topic gets\n    merged to 'master'.  We often call this 'graduating'.\n\n 8. Any further updates (enhancements and bugfixes) to the already\n    graduated topic goes through the same cycle as a new and\n    independent topic, starting from #1.\n\nThe time taken during the 1..3 cycle and number of iterations to get\nright cannot be really shrunk without making our developers work\nharder and there are only 24 hours in a day.  And I do not think we\ncan realistically \"make our developers work hader\", as everybody's\npriority is different.\n\nThe time taken during 7. is pretty much fixed and unless we are\nwilling to sacrifice the quality of the end result, cannot\nreasonably be shortened (note that this is based on the assumption\nthat \"find any remaining bugs while it is in 'next' before it hits\n'master'\" philosophy is working, but we have never run experiments\nto shorten this to say 3 days to see if we see more bugs on 'master'\nyet).\n\nBut I wonder if 5. can be accellerated without sacrificing the\nquality of the end result, every time I send out a \"ping\" e-mail to\nold discussion thread, with \"The discussion seems to have petered\nout at this point.  Is everybody happy?\"  Either I could have sent\nsuch \"ping\"s earlier, or reviewers who were involved in the review\ncould have given a positive \"oh, this looks good. let's declare a\nvictory\" sooner.  Of course, from the point of view of distributing\nthe load and making the process as parallelized as possible, the\nlatter is more preferrable.\n\nLet's take a handful of topics that graduated to 'master' on\n2025-09-23 and examine how much they spent in each phase.\n\n  * cs/subtree-squash-split-fix: The topic took 3 iterations (v1:\n    2025-08-24, v2: 2025-09-05, v3: 2025-09-10).\n\n  After <dd71ebee-8629-43c3-aa2a-40124400f262@gmail.com> gave an Ack,\n  the topic was picked up to 'seen' on 2025-09-11, and then 42063163\n  (Merge branch 'cs/subtree-squash-split-fix' into next, 2025-09-15)\n  merged it to 'next'.  We probably could have merged it to 'next' a\n  few days earlier.\n\n  * rs/get-oid-with-flags-cleanup: a single iteration (2025-09-10)\n\n  The topic was picked up to 'seen' on the same day,\n  <aMevTM6YESMDdWPh@pks.im> gave an ack on 2025-09-15, triggering\n  its merge to 'next' on the same day at ff8d1faa (Merge branch\n  'rs/get-oid-with-flags-cleanup' into next, 2025-09-15).  I think\n  this is an example of the process working perfectly for an\n  uncontroversially good small change.\n\n  * jk/add-i-color: 2 iterations (v1: 2025-08-21, v2: 2025-09-08).\n\n  The first iteration was sent on 2025-08-21 after a bug report filed\n  on the previous day.  After a few review exchanges starting\n  2025-09-03, the second iteration sent on 2025-09-08 was acked on the\n  next day.  The topic was merged on 2025-09-15, after spending a week\n  in 'seen' outside 'next'.  I do not recall the details, but perhaps\n  it was during relatively busy period, or there were topics that\n  touched overlapping areas, or something?  Or perhaps maintainer\n  fatigue?\n\n  * cc/promisor-remote-capability: 8 iterations (v1: 2025-04-14,\n    v2: 2025-04-29, v3: 2025-05-19, v4: 2025-06-11, v5: 2025-06-25,\n    v6: 2025-07-21, v7: 2025-07-31, v8: 2025-09-08).\n\n  Past round 4 or so we started seeing fewer reviews if any.  The\n  topic has lived almost since its inception in 'seen' until the last\n  round was merged to 'next' at 367d83c0 (Merge branch\n  'cc/promisor-remote-capability' into next, 2025-09-15).  Again, this\n  last round wasted 7 days in 'seen' without any activity, which I\n  wonder if we could have somehow avoided?\n\nOpinions and ideas to help topics not to waste too much time waiting\nfor step 5. is very much appreciated.  The most radical idea I can\nthink if is to introduce two more \"maintainers\" and any two of them\ncan vote to merge a topic in 'seen' to 'next' without waiting for\nthe other maintainer, but there may be simpler approaches that do\nnot require huge workflow changes.\n\nThanks.\n"},{"id":"527498","messageId":"aNhX9AJ/zq4IYhmW@nand.local","threadId":"64216","inReplyTo":"xmqqldm0am4b.fsf@gitster.g","subject":"Re: [RFC] How to accellerate the patch flow (or should we?)","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2025-09-27T21:32:36Z","receivedAt":"2025-09-27T21:32:40Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Fri, Sep 26, 2025 at 03:24:04PM -0700, Junio C Hamano wrote:\n>  4. While the above cycle is running, the maintainer may queue it in\n>     'seen', for two purposes.  (1) not to lose sight and forget\n>     about the change.  (2) to catch potential conflicts and overlaps\n>     with other in-flight topics to keep their interaction manageable.\n\nPerhaps a third purpose is to let the maintainer (or those who use\nand/or build off of 'seen' as their daily driver) detect any bugs in\nthat topic, or via interaction with other topics in 'seen'.\n\n> The time taken during 7. is pretty much fixed and unless we are\n> willing to sacrifice the quality of the end result, cannot\n> reasonably be shortened (note that this is based on the assumption\n> that \"find any remaining bugs while it is in 'next' before it hits\n> 'master'\" philosophy is working, but we have never run experiments\n> to shorten this to say 3 days to see if we see more bugs on 'master'\n> yet).\n\nI have mixed feelings about this. On the one hand, I am a little\nuncomfortable with the idea of shortening the time in 'next' to fewer\nthan 7 days. I, too, have the feeling that having more time in 'next'\ngives us a greater chance of spotting bugs in a topic that is otherwise\ndestined for 'master'.\n\nOn the other hand, how many people are using 'next' as their daily\ndriver? Of those, how many are actively looking for bugs in the topics\nthat are in master..next. And of those, how many are actually triggering\nunique code paths that would expose those bugs in the first place?\n\nI have a vague recollection that Google internally has their engineers\nrun a version of Git that is based on 'next'. But after spending a few\nminutes searching through the list archives, I can't seem to find any\nrecord of that.\n\nAssuming that Google does provide a large user-base for 'next', I think\nwe could reasonably experiment with shortening the time that topics cook\nin 'next' before graduating, and compare how many bug reports we get.\nOtherwise (if Google is not daily-driving 'next'), I think that we could\nstill run that experiment, but I think it carries somewhat higher risk.\n\n(In either case, if we were to run that experiment, I'd suggest that we\ndo it towards the beginning of a release cycle. That will give us as\nmuch time as possible to squash any extra bugs that might make it to\n'master' without having to quickly revert out topics towards the end of\na cycle.)\n\n> But I wonder if 5. can be accellerated without sacrificing the\n> quality of the end result, every time I send out a \"ping\" e-mail to\n> old discussion thread, with \"The discussion seems to have petered\n> out at this point.  Is everybody happy?\"  Either I could have sent\n> such \"ping\"s earlier, or reviewers who were involved in the review\n> could have given a positive \"oh, this looks good. let's declare a\n> victory\" sooner.  Of course, from the point of view of distributing\n> the load and making the process as parallelized as possible, the\n> latter is more preferrable.\n\nI found that this was somewhat burdensome the few times that I have\nserved as interim-maintainer. I think that too often (and I am guilty of\nthis myself) reviewers will comment on a handful of patches, and, if\nthey don't have any blocking feedback, leave it at that when they would\notherwise be happy to see it merged.\n\nI know that we have talked about encouraging more reviewers to give a\n\"stamp of approval\" by responding to the cover letter with an \"ack\" or\n\"this looks ready to merge\". When that does happen, it's very useful for\nthe maintainer. But when it doesn't, it leaves the maintainer in an\nawkward spot of having to keep track of all pending topics on the list\nand how long they have been quiet for.\n\nMaybe tooling could help with this. But I think that we could also push\nourselves to be more proactive through policy changes. What if we\nrequired that (unless the maintainer wants to unilaterally merge a\ntopic) that at least one other reviewer must give it a positive \"ack\"\nbefore the maintainer starts merging it down?\n\n(As a side-observation, that matches with my expeirence in how code\nreview is done at GitHub, where at least one other person must provide\nan approving review, as opposed to just not leaving any blocking\nfeedback.)\n\nThat would leave topics which do not have active reviewers in a lurch,\nbut I think that is sort of the point. Contributors should expect to do\nsome of the work of making sure their topics get reviewed themselves,\nand that shouldn't fall entirely on the maintainer.\n\n>   * cc/promisor-remote-capability: 8 iterations (v1: 2025-04-14,\n>     v2: 2025-04-29, v3: 2025-05-19, v4: 2025-06-11, v5: 2025-06-25,\n>     v6: 2025-07-21, v7: 2025-07-31, v8: 2025-09-08).\n>\n>   Past round 4 or so we started seeing fewer reviews if any.  The\n>   topic has lived almost since its inception in 'seen' until the last\n>   round was merged to 'next' at 367d83c0 (Merge branch\n>   'cc/promisor-remote-capability' into next, 2025-09-15).  Again, this\n>   last round wasted 7 days in 'seen' without any activity, which I\n>   wonder if we could have somehow avoided?\n\nI haven't followed this series closely, but I feel like subjectively\nhaving had my own series get into the v5-and-beyond range, that is\nusually a signal that the topic is too complex/large and needs to be\nsplit up. Not a critique of cc/promisor-remote-capability in particular,\njust a general observation.\n\n> Opinions and ideas to help topics not to waste too much time waiting\n> for step 5. is very much appreciated.  The most radical idea I can\n> think if is to introduce two more \"maintainers\" and any two of them\n> can vote to merge a topic in 'seen' to 'next' without waiting for\n> the other maintainer, but there may be simpler approaches that do\n> not require huge workflow changes.\n\nThe best that I can come up with is the above (one or more contributors\nmust provide a positive \"ack\" before the maintainer merges a topic, up\nto the maintainer's discretion). I think something like the following\nwould be worth trying:\n\n--- 8< ---\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex 86ca7f6a78a..789febefff8 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -506,7 +506,10 @@ After the list reached a consensus that it is a good idea to apply the\n patch, re-send it with \"To:\" set to the maintainer{current-maintainer}\n and \"cc:\" the list{git-ml} for inclusion.  This is especially relevant\n when the maintainer did not heavily participate in the discussion and\n-instead left the review to trusted others.\n+instead left the review to trusted others.  Patch series must receive\n+a positive \"ack\" from at least one contributor other than the primary\n+patch series author in order to begin integrating it, subject to the\n+maintainer's discretion.\n\n Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and\n `Tested-by:` lines as necessary to credit people who helped your\n--- >8 ---\n\nI am not sure the idea of adding more maintainers is a good one or not.\nSince I am not sure exactly what you are envisioning here, I think there\nare a couple of cases:\n\n - There is a quorum of maintainers, who are all collectively\n   responsible for building 'jch', 'seen', 'next', and 'master'. Any two\n   of them are required to agree to move a topic down in order to do so,\n   without needing the other maintainer to weigh in.\n\n - There are sub-system maintainers who are responsible for their own\n   trees, and who send pull requests to the primary maintainer to\n   integrate their trees back into the primary maintainer's.\n\nThe \"quorum of maintainers\" idea has a couple of drawbacks. Unless one\nmaintainer has the special role of being able to unilaterally merge\ntopics, each topic would require twice as many maintainers as we\ncurrently have in order to merge it down ;-). I could also imagine there\nbeing some coordination overhead between maintainers when shuffling who\nis building the integration branches to make sure that topics don't\nmysteriously get added or dropped when shuffling between maintainers.\n\nI don't have strong feelings against the idea of having sub-system\nmaintainers, but I am also skeptical that it will meaningfully speed up\ndevelopment. For any sub-system that has enough active contributors to\nfind a suitable sub-system maintainer, it is likely that patches in that\narea are already getting reviewed (and hopefully merged) quickly.\n\nIt's the areas that don't have enough active contributors to have a\nreliable sub-system maintainer that I worry about. Those areas are\nalready likely struggling to get patches reviewed and merged, but I am\nnot sure where we would even find a sub-system maintainer for those\nareas in the hopes of speeding it up.\n\nI think that last point is an argument in favor of the \"must have a\npositive 'ack'\" rule above. It flips the responsibility of finding\nreviewers back onto the contributors, and encourages more people to\nbecome reviewers in new areas. In other words, if a contributor wants to\nwrite patches in a area that traditionally struggles to get timely\nreviews, they are incentivized to find and encourage new reviewers to\nwork in that area, which is a net benefit to the project.\n\nSo, I dunno. I guess I had more thoughts about this than I expected to,\nbut I would be interested in trying either shortening the period topics\ncook in 'next', or trying out the \"must receive a positive 'ack'\" rule.\n\nThanks,\nTaylor\n"},{"id":"527500","messageId":"xmqqseg777k8.fsf@gitster.g","threadId":"64216","inReplyTo":"aNhX9AJ/zq4IYhmW@nand.local","subject":"Re: [RFC] How to accellerate the patch flow (or should we?)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-09-28T00:19:03Z","receivedAt":"2025-09-28T00:19:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau <me@ttaylorr.com> writes:\n\n>> ... (note that this is based on the assumption\n>> that \"find any remaining bugs while it is in 'next' before it hits\n>> 'master'\" philosophy is working, but we have never run experiments\n>> to shorten this to say 3 days to see if we see more bugs on 'master'\n>> yet).\n> ...\n> I have a vague recollection that Google internally has their engineers\n> run a version of Git that is based on 'next'. But after spending a few\n> minutes searching through the list archives, I can't seem to find any\n> record of that.\n\nThey do, but the frequency they update desktop installations is lower\nthan the frequency I merge new topics to update the tip of 'next', so\nI suspect they alone would not be sufficient guinea pigs.\n\n> Maybe tooling could help with this. But I think that we could also push\n> ourselves to be more proactive through policy changes. What if we\n> required that (unless the maintainer wants to unilaterally merge a\n> topic) that at least one other reviewer must give it a positive \"ack\"\n> before the maintainer starts merging it down?\n> ...\n> The best that I can come up with is the above (one or more contributors\n> must provide a positive \"ack\" before the maintainer merges a topic, up\n> to the maintainer's discretion). I think something like the following\n> would be worth trying:\n>\n> --- 8< ---\n> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\n> index 86ca7f6a78a..789febefff8 100644\n> --- a/Documentation/SubmittingPatches\n> +++ b/Documentation/SubmittingPatches\n> @@ -506,7 +506,10 @@ After the list reached a consensus that it is a good idea to apply the\n>  patch, re-send it with \"To:\" set to the maintainer{current-maintainer}\n>  and \"cc:\" the list{git-ml} for inclusion.  This is especially relevant\n>  when the maintainer did not heavily participate in the discussion and\n> -instead left the review to trusted others.\n> +instead left the review to trusted others.  Patch series must receive\n> +a positive \"ack\" from at least one contributor other than the primary\n> +patch series author in order to begin integrating it, subject to the\n> +maintainer's discretion.\n>\n>  Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and\n>  `Tested-by:` lines as necessary to credit people who helped your\n> --- >8 ---\n\nIt would lead us into ugly awkwardness when we start clarifying what\nexactly \"contributor\" is in the new sentence, though.  If a person,\nwhom none of us have ever heard of, sends their first message to\nthis list saying \"Ack\", does that count?  If an active developer,\nwho is known to be sloppier than others, sends an \"Ack\" to somebody\nelse's patch that was posted 3 hours before (hence there wouldn't\nhave sufficient time to think through the issues), how much should\nthat \"Ack\" weigh?\n\nPerhaps rephrasing it to \"those who have helped in polishing the\npatches with their reviews and discussing the issues with the patch\nauthor\" to tighten the language a bit may help?\n\nI dunno, as that would still give the \"ack right\" to a random\nnoisemaker who threw a drive-by \"review\" that did not add much value\nto the patches, if the original author responded \"Thanks\" out of\ncourtesy.\n\n> I am not sure the idea of adding more maintainers is a good one or not.\n> Since I am not sure exactly what you are envisioning here, I think there\n> are a couple of cases:\n>\n>  - There is a quorum of maintainers, who are all collectively\n>    responsible for building 'jch', 'seen', 'next', and 'master'. Any two\n>    of them are required to agree to move a topic down in order to do so,\n>    without needing the other maintainer to weigh in.\n>\n>  - There are sub-system maintainers who are responsible for their own\n>    trees, and who send pull requests to the primary maintainer to\n>    integrate their trees back into the primary maintainer's.\n\nGit is not large enough to benefit from the latter arrangement.\nWhat I had in mind was the former one.\n\n> The \"quorum of maintainers\" idea has a couple of drawbacks. Unless one\n> maintainer has the special role of being able to unilaterally merge\n> topics, each topic would require twice as many maintainers as we\n> currently have in order to merge it down ;-). I could also imagine there\n> being some coordination overhead between maintainers when shuffling who\n> is building the integration branches to make sure that topics don't\n> mysteriously get added or dropped when shuffling between maintainers.\n\nTrue.  It was a strawman to invite other more realistic ideas (like\nyour \"positive ack required\"), and was not necessarily designed to\nbe workable ;-).\n"},{"id":"527502","messageId":"aNiblmQxtZyigbcu@nand.local","threadId":"64216","inReplyTo":"xmqqseg777k8.fsf@gitster.g","subject":"Re: [RFC] How to accellerate the patch flow (or should we?)","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2025-09-28T02:21:15Z","receivedAt":"2025-09-28T02:21:24Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Sat, Sep 27, 2025 at 05:19:03PM -0700, Junio C Hamano wrote:\n> Taylor Blau <me@ttaylorr.com> writes:\n>\n> >> ... (note that this is based on the assumption\n> >> that \"find any remaining bugs while it is in 'next' before it hits\n> >> 'master'\" philosophy is working, but we have never run experiments\n> >> to shorten this to say 3 days to see if we see more bugs on 'master'\n> >> yet).\n> > ...\n> > I have a vague recollection that Google internally has their engineers\n> > run a version of Git that is based on 'next'. But after spending a few\n> > minutes searching through the list archives, I can't seem to find any\n> > record of that.\n>\n> They do, but the frequency they update desktop installations is lower\n> than the frequency I merge new topics to update the tip of 'next', so\n> I suspect they alone would not be sufficient guinea pigs.\n\nGood to know, and yeah, if Googlers aren't receiving 'next' updates as\nfrequently as the maintainer is producing them, then I don't think that\nincreases the risk of shortening the period for which topics cook on\n'next' before graduating.\n\n> It would lead us into ugly awkwardness when we start clarifying what\n> exactly \"contributor\" is in the new sentence, though.  If a person,\n> whom none of us have ever heard of, sends their first message to\n> this list saying \"Ack\", does that count?  If an active developer,\n> who is known to be sloppier than others, sends an \"Ack\" to somebody\n> else's patch that was posted 3 hours before (hence there wouldn't\n> have sufficient time to think through the issues), how much should\n> that \"Ack\" weigh?\n>\n> Perhaps rephrasing it to \"those who have helped in polishing the\n> patches with their reviews and discussing the issues with the patch\n> author\" to tighten the language a bit may help?\n>\n> I dunno, as that would still give the \"ack right\" to a random\n> noisemaker who threw a drive-by \"review\" that did not add much value\n> to the patches, if the original author responded \"Thanks\" out of\n> courtesy.\n\nGood point. Having a REVIEWERS file might help with that. Perhaps that\nfile starts with just you on it, and then it can be expanded to form a\nnetwork of trusted reviewers over time.\n\nBuilding on the \"how code review is done at GitHub\" thing... GitHub has\na concept of required reviewers for PRs based on what file(s) are\nmodified as a part of the PR via its CODEOWNERS file. I share your\nfeeling below that the project is not large enough to have individual\nareas have separate groups of reviewers, so perhaps just a single list\nis fine.\n\n> True.  It was a strawman to invite other more realistic ideas (like\n> your \"positive ack required\"), and was not necessarily designed to\n> be workable ;-).\n\n;-).\n\nThanks,\nTaylor\n"},{"id":"527595","messageId":"87792693-58d9-4047-beae-38aa4c59ed41@app.fastmail.com","threadId":"64216","inReplyTo":"xmqqldm0am4b.fsf@gitster.g","subject":"Re: [RFC] How to accellerate the patch flow (or should we?)","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-09-29T20:04:49Z","receivedAt":"2025-09-29T20:05:17Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Sat, Sep 27, 2025, at 00:24, Junio C Hamano wrote:\n> A typical lifecycle of a patch series sent to the list ought to be\n> as follows:\n>\n>[snip]\n>  7. If 7 calendar days passes since the topic was merged to 'next'\n>     (or any incremental fixes are also added and merged to 'next')\n>     without any further finding of more problems, the topic gets\n>     merged to 'master'.  We often call this 'graduating'.\n>\n>[snip]\n> The time taken during 7. is pretty much fixed and unless we are\n> willing to sacrifice the quality of the end result, cannot\n> reasonably be shortened (note that this is based on the assumption\n> that \"find any remaining bugs while it is in 'next' before it hits\n> 'master'\" philosophy is working, but we have never run experiments\n> to shorten this to say 3 days to see if we see more bugs on 'master'\n> yet).\n\nMaybe pure documentation changes could cook for less than seven days.\nNot for the benefit of graduating to `master` faster but for the\nbenefits that less integration time brings:\n\n- Less integration overhead since things are less likely to touch the\n  same code (docs) at the same time\n- Less likely that you have to base new changes on pending series\n  - Integration overhead that affects both the contributor and the\n    maintainer\n- Potential second order effects like not being afraid of splitting up a\n  lengthy series into an uncontroversial preamble of pure fixes since\n  the combined series won’t have such a long potential lifespan\n\nGiven a documentation series that either fixes something or subjectively\n(by consensus) improves something, what’s the risk of cooking for\nslightly less than seven days?  You might introduce rendering\nregressions, which is not on the same order of badness that a software\nbug is.  And as for the subjectively improved documentation: people who\ndisagree on a subjective basis with a topic in `next` are already\nconsidered (?) a bit late to the party.\n\nAnd you also might miss out on feedback from people who run\n`Documentation/doc-diff origin/master origin/next` when they are\nbored.[1]  But again it doesn’t seem like a big risk or downside.\n\nYou still keep the same standard of review.  But save integration time.\n\n🔗 1: https://lore.kernel.org/git/df251b0c-c593-41ed-903e-8fb1c323b874@app.fastmail.com/\n\n-- \nKristoffer Haugsbakk\n"},{"id":"527596","messageId":"b583b17e-96a5-4f22-8cc4-acbd3dfec82b@app.fastmail.com","threadId":"64216","inReplyTo":"aNhX9AJ/zq4IYhmW@nand.local","subject":"Re: [RFC] How to accellerate the patch flow (or should we?)","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-09-29T20:12:31Z","receivedAt":"2025-09-29T20:12:54Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Sat, Sep 27, 2025, at 23:32, Taylor Blau wrote:\n> On Fri, Sep 26, 2025 at 03:24:04PM -0700, Junio C Hamano wrote:\n>>  4. While the above cycle is running, the maintainer may queue it in\n>>     'seen', for two purposes.  (1) not to lose sight and forget\n>>     about the change.  (2) to catch potential conflicts and overlaps\n>>     with other in-flight topics to keep their interaction manageable.\n>\n> Perhaps a third purpose is to let the maintainer (or those who use\n> and/or build off of 'seen' as their daily driver) detect any bugs in\n> that topic, or via interaction with other topics in 'seen'.\n>\n>> The time taken during 7. is pretty much fixed and unless we are\n>> willing to sacrifice the quality of the end result, cannot\n>> reasonably be shortened (note that this is based on the assumption\n>> that \"find any remaining bugs while it is in 'next' before it hits\n>> 'master'\" philosophy is working, but we have never run experiments\n>> to shorten this to say 3 days to see if we see more bugs on 'master'\n>> yet).\n>\n> I have mixed feelings about this. On the one hand, I am a little\n> uncomfortable with the idea of shortening the time in 'next' to fewer\n> than 7 days. I, too, have the feeling that having more time in 'next'\n> gives us a greater chance of spotting bugs in a topic that is otherwise\n> destined for 'master'.\n>\n> On the other hand, how many people are using 'next' as their daily\n> driver? Of those, how many are actively looking for bugs in the topics\n> that are in master..next. And of those, how many are actually triggering\n> unique code paths that would expose those bugs in the first place?\n\nTheoretically all the projects that make heavy use of git(1) could run\n`next` (and `master`) as an alternative configuration of their\nintegration tests.\n\n-- \nKristoffer\n"},{"id":"527599","messageId":"B0E6ED38-85AB-4D8B-BC72-9056086A28E5@gmail.com","threadId":"64216","inReplyTo":"b583b17e-96a5-4f22-8cc4-acbd3dfec82b@app.fastmail.com","subject":"Re: [RFC] How to accellerate the patch flow (or should we?)","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-09-29T21:19:47Z","receivedAt":"2025-09-29T21:19:59Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"\n> Le 29 sept. 2025 à 16:13, Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com> a écrit :\n> \n> On Sat, Sep 27, 2025, at 23:32, Taylor Blau wrote:\n>>> On Fri, Sep 26, 2025 at 03:24:04PM -0700, Junio C Hamano wrote:\n>>> 4. While the above cycle is running, the maintainer may queue it in\n>>>    'seen', for two purposes.  (1) not to lose sight and forget\n>>>    about the change.  (2) to catch potential conflicts and overlaps\n>>>    with other in-flight topics to keep their interaction manageable.\n>> \n>> Perhaps a third purpose is to let the maintainer (or those who use\n>> and/or build off of 'seen' as their daily driver) detect any bugs in\n>> that topic, or via interaction with other topics in 'seen'.\n>> \n>>> The time taken during 7. is pretty much fixed and unless we are\n>>> willing to sacrifice the quality of the end result, cannot\n>>> reasonably be shortened (note that this is based on the assumption\n>>> that \"find any remaining bugs while it is in 'next' before it hits\n>>> 'master'\" philosophy is working, but we have never run experiments\n>>> to shorten this to say 3 days to see if we see more bugs on 'master'\n>>> yet).\n>> \n>> I have mixed feelings about this. On the one hand, I am a little\n>> uncomfortable with the idea of shortening the time in 'next' to fewer\n>> than 7 days. I, too, have the feeling that having more time in 'next'\n>> gives us a greater chance of spotting bugs in a topic that is otherwise\n>> destined for 'master'.\n>> \n>> On the other hand, how many people are using 'next' as their daily\n>> driver? Of those, how many are actively looking for bugs in the topics\n>> that are in master..next. And of those, how many are actually triggering\n>> unique code paths that would expose those bugs in the first place?\n> \n> Theoretically all the projects that make heavy use of git(1) could run\n> `next` (and `master`) as an alternative configuration of their\n> integration tests.\n\nThis reminds me of crater from Rust: could we work with know “big users” in the ecosystems to run their tests against our next/master Git periodically? On every commit?\n"},{"id":"527601","messageId":"xmqq4isk7vrv.fsf@gitster.g","threadId":"64216","inReplyTo":"87792693-58d9-4047-beae-38aa4c59ed41@app.fastmail.com","subject":"Re: [RFC] How to accellerate the patch flow (or should we?)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-09-29T22:12:52Z","receivedAt":"2025-09-29T22:12:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kristoffer Haugsbakk\" <kristofferhaugsbakk@fastmail.com> writes:\n\n>> The time taken during 7. is pretty much fixed and unless we are\n>> willing to sacrifice the quality of the end result, cannot\n>> reasonably be shortened (note that this is based on the assumption\n>> that \"find any remaining bugs while it is in 'next' before it hits\n>> 'master'\" philosophy is working, but we have never run experiments\n>> to shorten this to say 3 days to see if we see more bugs on 'master'\n>> yet).\n>\n> Maybe pure documentation changes could cook for less than seven days.\n\nYup, that kind of adjustment at the maintainer's discretion has\nalready been applied, depending on the nature of a topic.  Some\ntruly trivial typofixes may not even go through 'next' but get\napplied to 'master' directly.\n\nThanks.\n\n\n\n"},{"id":"527604","messageId":"aNsG5Jd_YLgrwarI@pks.im","threadId":"64216","inReplyTo":"xmqqseg777k8.fsf@gitster.g","subject":"Re: [RFC] How to accellerate the patch flow (or should we?)","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-09-29T22:23:32Z","receivedAt":"2025-09-29T22:23:44Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Sat, Sep 27, 2025 at 05:19:03PM -0700, Junio C Hamano wrote:\n> Taylor Blau <me@ttaylorr.com> writes:\n> > diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\n> > index 86ca7f6a78a..789febefff8 100644\n> > --- a/Documentation/SubmittingPatches\n> > +++ b/Documentation/SubmittingPatches\n> > @@ -506,7 +506,10 @@ After the list reached a consensus that it is a good idea to apply the\n> >  patch, re-send it with \"To:\" set to the maintainer{current-maintainer}\n> >  and \"cc:\" the list{git-ml} for inclusion.  This is especially relevant\n> >  when the maintainer did not heavily participate in the discussion and\n> > -instead left the review to trusted others.\n> > +instead left the review to trusted others.  Patch series must receive\n> > +a positive \"ack\" from at least one contributor other than the primary\n> > +patch series author in order to begin integrating it, subject to the\n> > +maintainer's discretion.\n> >\n> >  Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and\n> >  `Tested-by:` lines as necessary to credit people who helped your\n> > --- >8 ---\n> \n> It would lead us into ugly awkwardness when we start clarifying what\n> exactly \"contributor\" is in the new sentence, though.  If a person,\n> whom none of us have ever heard of, sends their first message to\n> this list saying \"Ack\", does that count?  If an active developer,\n> who is known to be sloppier than others, sends an \"Ack\" to somebody\n> else's patch that was posted 3 hours before (hence there wouldn't\n> have sufficient time to think through the issues), how much should\n> that \"Ack\" weigh?\n> \n> Perhaps rephrasing it to \"those who have helped in polishing the\n> patches with their reviews and discussing the issues with the patch\n> author\" to tighten the language a bit may help?\n> \n> I dunno, as that would still give the \"ack right\" to a random\n> noisemaker who threw a drive-by \"review\" that did not add much value\n> to the patches, if the original author responded \"Thanks\" out of\n> courtesy.\n\nDespite the potential awkwardness I have to wonder whether this would\neven help us with the goal to speed up the overall process. To me it\nrather feels like there's another step now that a patch series has to go\nthrough, so my naive expectation is that it will rather slow the process\ndown even more.\n\nAm I missing something?\n\n> > I am not sure the idea of adding more maintainers is a good one or not.\n> > Since I am not sure exactly what you are envisioning here, I think there\n> > are a couple of cases:\n> >\n> >  - There is a quorum of maintainers, who are all collectively\n> >    responsible for building 'jch', 'seen', 'next', and 'master'. Any two\n> >    of them are required to agree to move a topic down in order to do so,\n> >    without needing the other maintainer to weigh in.\n> >\n> >  - There are sub-system maintainers who are responsible for their own\n> >    trees, and who send pull requests to the primary maintainer to\n> >    integrate their trees back into the primary maintainer's.\n> \n> Git is not large enough to benefit from the latter arrangement.\n> What I had in mind was the former one.\n\nTrue. The other problem I see is that it might also skew the rate of\npatches towards subsystems that have more active contribtors (or rather\nsubsystem maintainers). Other subsystems that don't have the luxury\nwould then potentially be disfavored.\n\nI guess this is especially an issue as the most active subsystems tend\nto be the ones maintained by hosting providers like GitLab and GitHub.\nDrive-by contributions on the other hand tend to be more cluttered\naround different parts of Git, and here it's unlikely that we have\nenough people to serve as subsystem maintainers.\n\nPatrick\n"},{"id":"527605","messageId":"aNsG8JGvpzui7XJA@pks.im","threadId":"64216","inReplyTo":"aNhX9AJ/zq4IYhmW@nand.local","subject":"Re: [RFC] How to accellerate the patch flow (or should we?)","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-09-29T22:23:44Z","receivedAt":"2025-09-29T22:23:49Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Sat, Sep 27, 2025 at 05:32:36PM -0400, Taylor Blau wrote:\n> That would leave topics which do not have active reviewers in a lurch,\n> but I think that is sort of the point. Contributors should expect to do\n> some of the work of making sure their topics get reviewed themselves,\n> and that shouldn't fall entirely on the maintainer.\n\nI guess this is a realistic expectation for oldtimers on the mailing\nlist. And it especially is a possibility for developers that work in a\nteam, as they can basically tell others to do a review. But newcomers\nalready have a hard time to contribute to Git, so we should make sure\nthat we don't put more of the burden on them.\n\nPatrick\n"},{"id":"527606","messageId":"aNsG9kmkfoToSmAD@pks.im","threadId":"64216","inReplyTo":"b583b17e-96a5-4f22-8cc4-acbd3dfec82b@app.fastmail.com","subject":"Re: [RFC] How to accellerate the patch flow (or should we?)","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-09-29T22:23:50Z","receivedAt":"2025-09-29T22:23:55Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Sep 29, 2025 at 10:12:31PM +0200, Kristoffer Haugsbakk wrote:\n> On Sat, Sep 27, 2025, at 23:32, Taylor Blau wrote:\n> > On Fri, Sep 26, 2025 at 03:24:04PM -0700, Junio C Hamano wrote:\n> >>  4. While the above cycle is running, the maintainer may queue it in\n> >>     'seen', for two purposes.  (1) not to lose sight and forget\n> >>     about the change.  (2) to catch potential conflicts and overlaps\n> >>     with other in-flight topics to keep their interaction manageable.\n> >\n> > Perhaps a third purpose is to let the maintainer (or those who use\n> > and/or build off of 'seen' as their daily driver) detect any bugs in\n> > that topic, or via interaction with other topics in 'seen'.\n> >\n> >> The time taken during 7. is pretty much fixed and unless we are\n> >> willing to sacrifice the quality of the end result, cannot\n> >> reasonably be shortened (note that this is based on the assumption\n> >> that \"find any remaining bugs while it is in 'next' before it hits\n> >> 'master'\" philosophy is working, but we have never run experiments\n> >> to shorten this to say 3 days to see if we see more bugs on 'master'\n> >> yet).\n> >\n> > I have mixed feelings about this. On the one hand, I am a little\n> > uncomfortable with the idea of shortening the time in 'next' to fewer\n> > than 7 days. I, too, have the feeling that having more time in 'next'\n> > gives us a greater chance of spotting bugs in a topic that is otherwise\n> > destined for 'master'.\n> >\n> > On the other hand, how many people are using 'next' as their daily\n> > driver? Of those, how many are actively looking for bugs in the topics\n> > that are in master..next. And of those, how many are actually triggering\n> > unique code paths that would expose those bugs in the first place?\n> \n> Theoretically all the projects that make heavy use of git(1) could run\n> `next` (and `master`) as an alternative configuration of their\n> integration tests.\n\nAt GitLab we do: we have nightly CI runs that execute our integration\ntests with both `next` and `master`. This has already surfaced issues at\nseveral points in time. We also have plans to roll out `next` to all of\nour developers, but we haven't gotten around to this one yet.\n\nGiven the daily schedule of the CI runs it would be _okayish_ to reduce\nthe 7 days to something shorter. But realistically, not every pipeline\nfailure is noticed immediately, and sometimes we have different\npriorities before we can dive into the pipeline failure.\n\nThe same is basically true for those companies that deploy to their devs\nfrom `next`. There is a certain roundtrip time: the new version has to\nbe deployed, people have to start using it, and the bug reports have to\ntrickle back to the Git teams before they become actionable.\n\nSo I don't really feel like we can significantly reduce these 7 days\nwithout losing some of the safety.\n\nPatrick\n"},{"id":"527608","messageId":"xmqqqzvo6fmw.fsf@gitster.g","threadId":"64216","inReplyTo":"aNsG5Jd_YLgrwarI@pks.im","subject":"Re: [RFC] How to accellerate the patch flow (or should we?)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-09-29T22:46:47Z","receivedAt":"2025-09-29T22:46:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> Despite the potential awkwardness I have to wonder whether this would\n> even help us with the goal to speed up the overall process. To me it\n> rather feels like there's another step now that a patch series has to go\n> through, so my naive expectation is that it will rather slow the process\n> down even more.\n>\n> Am I missing something?\n\nThe above is an effort to reduce the chance/risk that the maintainer\nis *not* made aware of the fact that a topic has already been well\nreviewed, or the latest reroll has addressed all the issues\npreviously have pointed out and the reviewers are happy with its\nshape, and ready to be merged to 'next', just left in 'seen' labeled\nwith \"Will merge to 'next'?\", etc.\n"},{"id":"527619","messageId":"aNsVT_OWOCAB3fzO@pks.im","threadId":"64216","inReplyTo":"xmqqqzvo6fmw.fsf@gitster.g","subject":"Re: [RFC] How to accellerate the patch flow (or should we?)","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-09-29T23:25:03Z","receivedAt":"2025-09-29T23:25:08Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Sep 29, 2025 at 03:46:47PM -0700, Junio C Hamano wrote:\n> Patrick Steinhardt <ps@pks.im> writes:\n> \n> > Despite the potential awkwardness I have to wonder whether this would\n> > even help us with the goal to speed up the overall process. To me it\n> > rather feels like there's another step now that a patch series has to go\n> > through, so my naive expectation is that it will rather slow the process\n> > down even more.\n> >\n> > Am I missing something?\n> \n> The above is an effort to reduce the chance/risk that the maintainer\n> is *not* made aware of the fact that a topic has already been well\n> reviewed, or the latest reroll has addressed all the issues\n> previously have pointed out and the reviewers are happy with its\n> shape, and ready to be merged to 'next', just left in 'seen' labeled\n> with \"Will merge to 'next'?\", etc.\n\nAh, okay, that makes more sense then. So basically, reviewers should\nmore explicitly state their overall opinion on a patch series so that it\nbecomes easier for you to figure out the current state at a glance?\n\nPatrick\n"},{"id":"527660","messageId":"aNw3VY7npZvHDU7i@nand.local","threadId":"64216","inReplyTo":"aNsG5Jd_YLgrwarI@pks.im","subject":"Re: [RFC] How to accellerate the patch flow (or should we?)","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2025-09-30T20:02:29Z","receivedAt":"2025-09-30T20:02:33Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Tue, Sep 30, 2025 at 12:23:32AM +0200, Patrick Steinhardt wrote:\n> > It would lead us into ugly awkwardness when we start clarifying what\n> > exactly \"contributor\" is in the new sentence, though.  If a person,\n> > whom none of us have ever heard of, sends their first message to\n> > this list saying \"Ack\", does that count?  If an active developer,\n> > who is known to be sloppier than others, sends an \"Ack\" to somebody\n> > else's patch that was posted 3 hours before (hence there wouldn't\n> > have sufficient time to think through the issues), how much should\n> > that \"Ack\" weigh?\n> >\n> > Perhaps rephrasing it to \"those who have helped in polishing the\n> > patches with their reviews and discussing the issues with the patch\n> > author\" to tighten the language a bit may help?\n> >\n> > I dunno, as that would still give the \"ack right\" to a random\n> > noisemaker who threw a drive-by \"review\" that did not add much value\n> > to the patches, if the original author responded \"Thanks\" out of\n> > courtesy.\n>\n> Despite the potential awkwardness I have to wonder whether this would\n> even help us with the goal to speed up the overall process. To me it\n> rather feels like there's another step now that a patch series has to go\n> through, so my naive expectation is that it will rather slow the process\n> down even more.\n>\n> Am I missing something?\n\nThe idea is that it would make things possibly quicker, but never\nslower. Since the maintainer is also part of the \"trusted ack-ers\", the\nonly process change would be that the maintainer could choose to avoid\nreading a series closely if it has already received an ack.\n\n(As an aside, in the pseudo-patch I wrote above, the maintainer could\nchoose to bypass the process entirely, since it would continue to be at\ntheir discretion. Perhaps that's just a semantics thing, since by\nmerging the series the maintainer is implicitly providing their own\n\"ack\", without actually saying so.)\n\n> I guess this is especially an issue as the most active subsystems tend\n> to be the ones maintained by hosting providers like GitLab and GitHub.\n> Drive-by contributions on the other hand tend to be more cluttered\n> around different parts of Git, and here it's unlikely that we have\n> enough people to serve as subsystem maintainers.\n\nYeah... to be clear, the \"subsystem maintainers\" idea was really just me\nwondering aloud which of the two possible interpretations of what Junio\nsaid above would make the most sense to me.\n\nThanks,\nTaylor\n"},{"id":"527662","messageId":"aNw3z0E/xvJ/OChO@nand.local","threadId":"64216","inReplyTo":"aNsG8JGvpzui7XJA@pks.im","subject":"Re: [RFC] How to accellerate the patch flow (or should we?)","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2025-09-30T20:04:31Z","receivedAt":"2025-09-30T20:04:35Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Tue, Sep 30, 2025 at 12:23:44AM +0200, Patrick Steinhardt wrote:\n> On Sat, Sep 27, 2025 at 05:32:36PM -0400, Taylor Blau wrote:\n> > That would leave topics which do not have active reviewers in a lurch,\n> > but I think that is sort of the point. Contributors should expect to do\n> > some of the work of making sure their topics get reviewed themselves,\n> > and that shouldn't fall entirely on the maintainer.\n>\n> I guess this is a realistic expectation for oldtimers on the mailing\n> list. And it especially is a possibility for developers that work in a\n> team, as they can basically tell others to do a review. But newcomers\n> already have a hard time to contribute to Git, so we should make sure\n> that we don't put more of the burden on them.\n\nI think the roles would change slightly. I agree that newcomers should\nnot be entirely responsible for finding reviewers, and I don't think\nthat asking them to do that is entirely practical either.\n\nBut it's also impractical IMHO to expect that the maintainer doesn't\nhappen to lose track of a topic from time to time. Perhaps other\nseasoned contributors could step in to say, \"hey, this topic hasn't\ngotten reviewed. Perhaps X, Y, or Z might want to chime in?\".\n\nI dunno.\n\nThanks,\nTaylor\n"},{"id":"527664","messageId":"xmqqbjmr4re6.fsf@gitster.g","threadId":"64216","inReplyTo":"aNw3VY7npZvHDU7i@nand.local","subject":"Re: [RFC] How to accellerate the patch flow (or should we?)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-09-30T20:28:01Z","receivedAt":"2025-09-30T20:28:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau <me@ttaylorr.com> writes:\n\n> (As an aside, in the pseudo-patch I wrote above, the maintainer could\n> choose to bypass the process entirely, since it would continue to be at\n> their discretion. Perhaps that's just a semantics thing, since by\n> merging the series the maintainer is implicitly providing their own\n> \"ack\", without actually saying so.)\n\nThis is exactly the reason why I keep saying \"being in 'seen' has no\nmeaning other than I happened to have seen, not more than that\".\nA topic queued in 'seen' by default has no \"ack\" from me or anybody.\n"},{"id":"527720","messageId":"xmqqjz1e1jfb.fsf@gitster.g","threadId":"64216","inReplyTo":"aNsVT_OWOCAB3fzO@pks.im","subject":"Re: [RFC] How to accellerate the patch flow (or should we?)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-01T20:00:40Z","receivedAt":"2025-10-01T20:00:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> On Mon, Sep 29, 2025 at 03:46:47PM -0700, Junio C Hamano wrote:\n>> Patrick Steinhardt <ps@pks.im> writes:\n>> \n>> > Despite the potential awkwardness I have to wonder whether this would\n>> > even help us with the goal to speed up the overall process. To me it\n>> > rather feels like there's another step now that a patch series has to go\n>> > through, so my naive expectation is that it will rather slow the process\n>> > down even more.\n>> >\n>> > Am I missing something?\n>> \n>> The above is an effort to reduce the chance/risk that the maintainer\n>> is *not* made aware of the fact that a topic has already been well\n>> reviewed, or the latest reroll has addressed all the issues\n>> previously have pointed out and the reviewers are happy with its\n>> shape, and ready to be merged to 'next', just left in 'seen' labeled\n>> with \"Will merge to 'next'?\", etc.\n>\n> Ah, okay, that makes more sense then. So basically, reviewers should\n> more explicitly state their overall opinion on a patch series so that it\n> becomes easier for you to figure out the current state at a glance?\n\nIf they did so, it may reduce the time a topic wastes in limbo,\nwaiting for me to notice that it is ready.  What I do not know is if\nsuch an additional burden on reviewers would slow us down overall.\n\nThanks.\n"}]}