Elijah Newren [off-list ref] writes:
Will do; I'll also point out a few topics that have been reviewed but
haven't been picked up yet.
quoted
* en/ort-perf-batch-9 (2021-03-10) 8 commits
- diffcore-rename: avoid doing basename comparisons for irrelevant sources
- merge-ort: skip rename detection entirely if possible
- merge-ort: use relevant_sources to filter possible rename sources
- merge-ort: precompute whether directory rename detection is needed
- merge-ort: introduce wrappers for alternate tree traversal
- merge-ort: add data structures for an alternate tree traversal
- merge-ort: precompute subset of sources for which we need rename detection
- diffcore-rename: enable filtering possible rename sources
(this branch uses en/ort-perf-batch-8.)
More ort.
Can I suggest an alternate title? "merge-ort optimization of skipping
irrelevant renames" or anything that gets the idea of "skipping
irrelevant renames" in there.
Thanks.
quoted
* en/ort-perf-batch-8 (2021-02-26) 10 commits
(merged to 'next' on 2021-03-07 at f03b2c1acd)
+ diffcore-rename: compute dir_rename_guess from dir_rename_counts
+ diffcore-rename: limit dir_rename_counts computation to relevant dirs
+ diffcore-rename: compute dir_rename_counts in stages
+ diffcore-rename: extend cleanup_dir_rename_info()
+ diffcore-rename: move dir_rename_counts into dir_rename_info struct
+ diffcore-rename: add function for clearing dir_rename_count
+ Move computation of dir_rename_count from merge-ort to diffcore-rename
+ diffcore-rename: add a mapping of destination names to their indices
+ diffcore-rename: provide basic implementation of idx_possible_rename()
+ diffcore-rename: use directory rename guided basename comparisons
(this branch is used by en/ort-perf-batch-9.)
Rename detection rework continues.
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".
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.
* 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.
On Thu, Mar 18, 2021 at 3:43 PM Junio C Hamano [off-list ref] wrote:
Elijah Newren [off-list ref] writes:
quoted
quoted
* en/ort-perf-batch-8 (2021-02-26) 10 commits
...
quoted
quoted
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.
quoted
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.
quoted
* 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