Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org, Phillip Wood <phillip.wood123@gmail.com>
Subject: Ejecting things more aggressively out of 'seen'?
Date: Sun, 01 Nov 2026 23:31:14 -0800	[thread overview]
Message-ID: <xmqq1p93ofjx.fsf@gitster.g> (raw)
In-Reply-To: <47bd0302-fc52-4df0-98a0-6fad7eb0fb05@gmail.com> (Phillip Wood's message of "Wed, 5 Aug 2026 14:10:39 +0100")

Phillip Wood <phillip.wood123@gmail.com> writes:

> On 29/07/2026 18:48, Junio C Hamano wrote:
>> 
>> Perhaps the sensible thing for me to do is to stop taking any new
>> topics into 'seen', even if I've spotted them, until I see somebody
>> give them a real review.
>> 
>> Otherwise, it becomes too tempting for me to jump in, give them a
>> superficial read after seeing them linger in the "What's Cooking"
>> draft in the "Needs review" state for too long, and, believing I've
>> seen enough, mark them for 'next'.  If I don't queue a patch that
>> nobody seems to have read carefully, I won't succumb to such
>> temptation.
>
> Maybe, though I do find having the patches in seen makes it easier to do 
> an in-depth review as it means I don't have to apply them myself.

I have operated in "aggressively accept many things into 'seen'"
mode for some time since this exchange.  We ended up with many
"Needs review" topics, which nobody was interested in, sitting in
'seen' for weeks.  Having these and other topics in 'seen' may have
helped other topics get reviewed, which might have been missed by
you and others if they were not in my tree in a readily available
form.  Thus, it is not entirely fair to declare this a failed
experiment.

Still, we need to decide, and better yet, establish a policy on, how
to deal with topics that remain unreviewed even after lingering in
'seen' for quite some time.

A mechanically applicable set of policies makes it easier to manage
a large volume of topics.  Some of these are currently written down,
while others may have been guessed by those who read a few "What's
cooking" reports in a row:

 - A topic that has spent a week in 'next' graduates to 'master',
   unless there is a strong reason to do otherwise.

 - A topic marked as "Will merge to 'next'" is merged 60 hours after
   such a label is applied (in other words, people can stop me if
   they act soon enough).

 - A topic goes into the "Waiting for response" state once reviewed,
   where it remains until the author responds.  After staying in
   this state for a month or so, it is demoted to the "Stalled"
   state, and eventually dropped.

We should probably have a rule that says "a topic that did not get
reviewed for N weeks is ejected from 'seen'".

Tonight, I am sending a notice for each topic that has been in that
state for more than a month (the oldest one dating back to mid-July).


  parent reply	other threads:[~2026-11-02  7:31 UTC|newest]

Thread overview: 21+ 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           ` Junio C Hamano [this message]
2026-11-02  9:59             ` Ejecting things more aggressively out of 'seen'? Patrick Steinhardt
2026-11-02 16:17               ` Junio C Hamano
2026-11-02 16:34                 ` Phillip Wood
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=xmqq1p93ofjx.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=phillip.wood123@gmail.com \
    /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