All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Phillip Wood <phillip.wood123@gmail.com>
Subject: Re: Ejecting things more aggressively out of 'seen'?
Date: Mon, 2 Nov 2026 10:59:43 +0100	[thread overview]
Message-ID: <auhfD1ryB-7JwOYl@pks.im> (raw)
In-Reply-To: <xmqq1p93ofjx.fsf@gitster.g>

On Sun, Nov 01, 2026 at 11:31:14PM -0800, Junio C Hamano wrote:
> 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).

One state that confuses newcomers quite often is "Will merge to 'next'?"
with a question mark at the end. If we were to document these we shuld
probably also document that state.

>  - 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'".

I think that's reasonable. Becoming a bit more aggressive there doesn't
make too much of a difference anyway -- if a topic gets evicted from
"seen" and then later on regains interest then it can still be included
into "seen" again.

By gut feeling I'd use the same rule as for "Waiting for response".

Patrick

  reply	other threads:[~2026-11-02  9:59 UTC|newest]

Thread overview: 25+ 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 [this message]
2026-11-02 16:17               ` Junio C Hamano
2026-11-02 16:34                 ` Phillip Wood
2026-11-06 20:38                   ` Junio C Hamano
2026-11-03  7:30                 ` Patrick Steinhardt
2026-11-03 16:04                   ` Junio C Hamano
2026-11-03 19:29                   ` Junio C Hamano
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=auhfD1ryB-7JwOYl@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.