[RFC] How to accellerate the patch flow (or should we?)

[Junio C Hamano <gitster@pobox.com>]

A typical lifecycle of a patch series sent to the list ought to be
as follows:

 1. You write a solution, describe the problem and solution in a
    patch series, send it to the list.

 2. People notice, take interest in, and comment on these patches.

 3. After #2 above, you may find it necessary to produce an updated
    version.  Go back to #1.

 4. While the above cycle is running, the maintainer may queue it in
    'seen', for two purposes.  (1) not to lose sight and forget
    about the change.  (2) to catch potential conflicts and overlaps
    with other in-flight topics to keep their interaction manageable.

 5. The maintainer notices that the discussion has reached a
    conclusion that the patch series is in a good shape, and merges
    it to 'next'.

 6. If a problem is found while the topic is in 'next', the topic
    may be marked as 'on hold' until an incremental solution to the
    problem is created.  This step may repeat while the topic is in
    'next'.  If the problem, which hasn't been noticed before #5
    happend, turns out to be so severe, the topic may have to be
    ejected out of 'next' for fresh restart.

 7. If 7 calendar days passes since the topic was merged to 'next'
    (or any incremental fixes are also added and merged to 'next')
    without any further finding of more problems, the topic gets
    merged to 'master'.  We often call this 'graduating'.

 8. Any further updates (enhancements and bugfixes) to the already
    graduated topic goes through the same cycle as a new and
    independent topic, starting from #1.

The time taken during the 1..3 cycle and number of iterations to get
right cannot be really shrunk without making our developers work
harder and there are only 24 hours in a day.  And I do not think we
can realistically "make our developers work hader", as everybody's
priority is different.

The time taken during 7. is pretty much fixed and unless we are
willing to sacrifice the quality of the end result, cannot
reasonably be shortened (note that this is based on the assumption
that "find any remaining bugs while it is in 'next' before it hits
'master'" philosophy is working, but we have never run experiments
to shorten this to say 3 days to see if we see more bugs on 'master'
yet).

But I wonder if 5. can be accellerated without sacrificing the
quality of the end result, every time I send out a "ping" e-mail to
old discussion thread, with "The discussion seems to have petered
out at this point.  Is everybody happy?"  Either I could have sent
such "ping"s earlier, or reviewers who were involved in the review
could have given a positive "oh, this looks good. let's declare a
victory" sooner.  Of course, from the point of view of distributing
the load and making the process as parallelized as possible, the
latter is more preferrable.

Let's take a handful of topics that graduated to 'master' on
2025-09-23 and examine how much they spent in each phase.

  * cs/subtree-squash-split-fix: The topic took 3 iterations (v1:
    2025-08-24, v2: 2025-09-05, v3: 2025-09-10).

  After <dd71ebee-8629-43c3-aa2a-40124400f262@gmail.com> gave an Ack,
  the topic was picked up to 'seen' on 2025-09-11, and then 42063163
  (Merge branch 'cs/subtree-squash-split-fix' into next, 2025-09-15)
  merged it to 'next'.  We probably could have merged it to 'next' a
  few days earlier.

  * rs/get-oid-with-flags-cleanup: a single iteration (2025-09-10)

  The topic was picked up to 'seen' on the same day,
  <aMevTM6YESMDdWPh@pks.im> gave an ack on 2025-09-15, triggering
  its merge to 'next' on the same day at ff8d1faa (Merge branch
  'rs/get-oid-with-flags-cleanup' into next, 2025-09-15).  I think
  this is an example of the process working perfectly for an
  uncontroversially good small change.

  * jk/add-i-color: 2 iterations (v1: 2025-08-21, v2: 2025-09-08).

  The first iteration was sent on 2025-08-21 after a bug report filed
  on the previous day.  After a few review exchanges starting
  2025-09-03, the second iteration sent on 2025-09-08 was acked on the
  next day.  The topic was merged on 2025-09-15, after spending a week
  in 'seen' outside 'next'.  I do not recall the details, but perhaps
  it was during relatively busy period, or there were topics that
  touched overlapping areas, or something?  Or perhaps maintainer
  fatigue?

  * cc/promisor-remote-capability: 8 iterations (v1: 2025-04-14,
    v2: 2025-04-29, v3: 2025-05-19, v4: 2025-06-11, v5: 2025-06-25,
    v6: 2025-07-21, v7: 2025-07-31, v8: 2025-09-08).

  Past round 4 or so we started seeing fewer reviews if any.  The
  topic has lived almost since its inception in 'seen' until the last
  round was merged to 'next' at 367d83c0 (Merge branch
  'cc/promisor-remote-capability' into next, 2025-09-15).  Again, this
  last round wasted 7 days in 'seen' without any activity, which I
  wonder if we could have somehow avoided?

Opinions and ideas to help topics not to waste too much time waiting
for step 5. is very much appreciated.  The most radical idea I can
think if is to introduce two more "maintainers" and any two of them
can vote to merge a topic in 'seen' to 'next' without waiting for
the other maintainer, but there may be simpler approaches that do
not require huge workflow changes.

Thanks.