Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org,  Phillip Wood <phillip.wood123@gmail.com>
Subject: Re: Ejecting things more aggressively out of 'seen'?
Date: Tue, 03 Nov 2026 11:29:42 -0800	[thread overview]
Message-ID: <xmqqh5hx7ly1.fsf@gitster.g> (raw)
In-Reply-To: <aumNkxzE7wfa519p@pks.im> (Patrick Steinhardt's message of "Tue, 3 Nov 2026 08:30:27 +0100")

Patrick Steinhardt <ps@pks.im> writes:

>> An obvious alternative is to queue only topics for which I can, by
>> judging reviews on the list, at least say "Will merge to 'next'?"
>> with enough confidence.  It would reduce the size of 'seen' and the
>> friction felt by contributors when their topic is once queued on
>> 'seen' and later ejected unceremoniously through no fault of their
>> own, other than their topic being forgettable or uninspiring to
>> others.
>
> Wouldn't we lose the ability to integrate topics with one another early
> on to see how they interact? And it makes me wonder whether this will
> overall slow down progress of a patch series if it gets merged to "seen"
> at a later point.

Even when I see a topic was reviewed by humans and reviewers find it
satisfactory standalone, it would not hit 'next' immediately.  We
are talking about topics that flow into 'seen' without attracting
interest by people.  Quite honestly, I do not think anybody should
care if these topics do not play well with other such topics.  It is
the job of topic authors to make sure what they write meshes well
with what is in flight, and not cluttering 'seen' with hopeless
topics would help those serious authors who do their homework.

Once a topic is found interesting standalone, it is very much in the
projects' interest to make sure it meshes well with other topics in
flight.  But not before.

> So maybe instead of someone saying that a patch series is ready, the bar
> should be that the patch series has gotten at least one human review
> that was somewhat favorable on the overall direction?

It has to be more like a trusted reviewer saying that it has
potential to be a reasonable change.

We shouldn't require perfection from the get go and instead expect
some more iterations after a topic hits 'seen'.  But it is a promise
to spend project resources on the topic to have it in 'seen'.  It
shouldn't be triggered by just a random drive-by commenter saying "I
want moon and this is it" without any believable explanation.

Thanks.

  parent reply	other threads:[~2026-11-03 19:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-27  3:09 What's cooking in git.git (Jul 2026, #12) Junio C Hamano
2026-07-29 13:24 ` Phillip Wood
2026-07-29 14:18   ` Junio C Hamano
2026-07-29 15:20     ` Phillip Wood
2026-07-29 17:48       ` Junio C Hamano
2026-08-05 13:10         ` Phillip Wood
2026-08-05 17:03           ` Junio C Hamano
2026-11-02  7:31           ` Ejecting things more aggressively out of 'seen'? Junio C Hamano
2026-11-02  9:59             ` Patrick Steinhardt
2026-11-02 16:17               ` Junio C Hamano
2026-11-02 16:34                 ` Phillip Wood
2026-11-03  7:30                 ` Patrick Steinhardt
2026-11-03 16:04                   ` Junio C Hamano
2026-11-03 19:29                   ` Junio C Hamano [this message]
2026-07-31  6:20     ` What's cooking in git.git (Jul 2026, #12) Matt Hunter
2026-07-31 15:36       ` Junio C Hamano
2026-07-30  6:11   ` Harald Nordgren
2026-07-31  7:02     ` Matt Hunter
2026-08-03  9:05       ` Phillip Wood
2026-08-03 16:02         ` Junio C Hamano
2026-08-04 13:19           ` Phillip Wood
2026-08-03  9:11     ` Phillip Wood
2026-07-29 15:14 ` Phillip Wood
2026-07-29 15:52   ` Junio C Hamano

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqh5hx7ly1.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=phillip.wood123@gmail.com \
    --cc=ps@pks.im \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox