git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Elijah Newren <newren@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: What's cooking in git.git (Mar 2021, #05; Wed, 17)
Date: Thu, 18 Mar 2021 18:04:05 -0700	[thread overview]
Message-ID: <CABPp-BHckvLF1q_Wr4=rC33BDg3o+4Ob+WUn0LGe6RwCM6DjjA@mail.gmail.com> (raw)
In-Reply-To: <xmqqeegcqe0t.fsf@gitster.g>

On Thu, Mar 18, 2021 at 3:43 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Elijah Newren <newren@gmail.com> writes:
>
> >> * en/ort-perf-batch-8 (2021-02-26) 10 commits
...
> >>  Will cook in 'next'.
> >
> > I think it's ready to merge to master.
>
> When a "will merge to 'next'" topic is merged to 'next', its label
> is mechanically rewritten to "will merge to 'master'" outside the
> pre-release freeze, and to "will cook in 'next'" while pre-release
> freeze.  So for the topics labelled with "Will cook in 'next'", by
> default they should turn into "Will merge to 'master'".
>
> That was why I was specifically asking for topics to be KICKED OUT
> of 'next', to give them a fresh start without having to do "oops,
> this was a mistake, let's patch it up".

Okay, color me confused.  You said in your original email:

"""
Many topics marked as "Will cook in 'next'" should be marked for
merging to 'master' now, but that hasn't happened yet.  Please
nominate those that should be kicked back from 'next' to 'seen', if
there are any.  Please also nominate those that should be among the
first batch of topics to be in 'master'.
"""

You had two "Please" statements in that paragrah.  I've nominated
topics for kicking-out before, but didn't know of any relevant topics
this time.  I did, however, think of one that I thought was worth
nominating for your second request.  Maybe I'm still misunderstanding
something important here, but I'm worried about exasperating you any
further so I'll just drop it.  I was trying to be helpful, sorry that
I wasn't.

> > Here are some reviewed topics that haven't been cooking yet, that I
> > personally think are worth picking up (at least for seen and probably
> > for next rather soonish):
>
> Thanks for a useful list of topics.  At this point, topics that are
> not picked up are not because they are not ready/worth, but because
> there are too many of them sent during the pre-release freeze.

Totally understood.  I wasn't trying to imply anything, I just know
it's hard to keep up with all the email (I honestly have no idea how
you do it as much as you do).  I know that especially when you're
busy, you might avoid picking up topics that look like they're just
going to continue churning.  I figured that it might be useful, out of
the topics not yet picked up, to highlight ones I knew of where the
current reviewers appeared to be happy at the state of the series.  If
my guesses at what might be helpful isn't, do let me know and I'll
avoid repeating.

> > * My ort-perf-batch-10 ("skip even more irrelevant renames") series:
> > https://lore.kernel.org/git/8422759a-a4a3-4dc6-4ae7-4a61896b9946@gmail.com/;
> > (the review comment there is addressed by the next patch series in
> > this list)
>
> There are 8, 9 and now this 10 in flight, which is two topics too
> many to have in flight at the same time X-<.  Luckily -8 seems to be
> good for 'master', so there is no risk of having to rewind it
> anymore, which makes the burden of having to carry multiple dependent
> topics at the same time.

Well 9 is "skip irrelevant renames" and 10 is "skip more irrelevant
renames" so they can be combined into one.  In fact, the "declare
merge ort stable" series was primarily addressing an issue reviewers
found with those series, so it could be lumped in too.  Would you like
me to resubmit that as one bigger series?  (The whole thing has been
reviewed by Stolee and about a third has been reviewed by Ævar, if
that matters to the answer.)

Also, moving forward, to avoid the risk of rewinds...

I had been trying to avoid the risk of rewinds by waiting until any
given series was fixed to the satisfaction of those who had spoken up
and reviewed it (and ensuring that included at least one person),
before I would submit another series.  If that's not sufficient, what
should I be doing instead?

Thanks,
Elijah

  reply	other threads:[~2021-03-19  1:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-17 22:21 What's cooking in git.git (Mar 2021, #05; Wed, 17) Junio C Hamano
2021-03-17 22:43 ` Ramsay Jones
     [not found]   ` <CAPc5daUBRFvDJzv059usPu89hcXiQELHqyNOhNVzB2aTKnS5aw@mail.gmail.com>
2021-03-17 23:17     ` Ramsay Jones
2021-03-17 23:13 ` Elijah Newren
2021-03-18 22:43   ` Junio C Hamano
2021-03-19  1:04     ` Elijah Newren [this message]
2021-03-19  1:53 ` 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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to='CABPp-BHckvLF1q_Wr4=rC33BDg3o+4Ob+WUn0LGe6RwCM6DjjA@mail.gmail.com' \
    --to=newren@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).