Hi everyone,
There will be ~11 more series (with about ~6-7 patches per series)
before merge-ort is complete. Now that gitster/en/merge-ort-perf has
merged to next, I can start submitting the next series. Some
questions before I do so, though:
* What's the right rate to submit them to not overwhelm reviewers? One
per week? I didn't get much feedback on this for the past series.
[One per week, assuming the git-2.32 cycle is 3 months long, would
mean finishing in about 3 months, i.e. just a few weeks before
git-2.32-rc0.]
* My focus for the next few series is on diffcore-rename.c, which will
also affect things other than merge-ort. While each series is
self-contained, given that 2.31-rc0 is just over 3 weeks away I'm
wondering if it makes sense to hold my future diffcore-rename series
out of 2.31 and start merging them in the 2.32 cycle. Thoughts?
Thanks,
Elijah
On 2/1/2021 10:52 PM, Elijah Newren wrote:
Hi everyone,
There will be ~11 more series (with about ~6-7 patches per series)
before merge-ort is complete. Now that gitster/en/merge-ort-perf has
merged to next, I can start submitting the next series. Some
questions before I do so, though:
quoted
* What's the right rate to submit them to not overwhelm reviewers? One
per week? I didn't get much feedback on this for the past series.
[One per week, assuming the git-2.32 cycle is 3 months long, would
mean finishing in about 3 months, i.e. just a few weeks before
git-2.32-rc0.]
I promise to get back to reviewing with a faster turnaround soon.
If these are smaller series (and ~6-7 patches per would be smaller)
then I could see most of them stabilizing within a week. I think the
biggest thing for dependent series is to allow one to stabilize
before starting the next one. OF course, we can _think_ something is
stable and then a contributor appears with insightful comments a week
or more later.
* My focus for the next few series is on diffcore-rename.c, which will
also affect things other than merge-ort. While each series is
self-contained, given that 2.31-rc0 is just over 3 weeks away I'm
wondering if it makes sense to hold my future diffcore-rename series
out of 2.31 and start merging them in the 2.32 cycle. Thoughts?
It might be fine to get the code under review, but ask Junio to
delay merging into 'master' until shortly after release. This
ensures that there is plenty of time to "simmer in CI."
Thanks,
-Stolee
On Tue, Feb 2, 2021 at 3:33 AM Derrick Stolee [off-list ref] wrote:
On 2/1/2021 10:52 PM, Elijah Newren wrote:
quoted
Hi everyone,
There will be ~11 more series (with about ~6-7 patches per series)
before merge-ort is complete. Now that gitster/en/merge-ort-perf has
merged to next, I can start submitting the next series. Some
questions before I do so, though:
quoted
* What's the right rate to submit them to not overwhelm reviewers? One
per week? I didn't get much feedback on this for the past series.
[One per week, assuming the git-2.32 cycle is 3 months long, would
mean finishing in about 3 months, i.e. just a few weeks before
git-2.32-rc0.]
I promise to get back to reviewing with a faster turnaround soon.
If these are smaller series (and ~6-7 patches per would be smaller)
then I could see most of them stabilizing within a week. I think the
biggest thing for dependent series is to allow one to stabilize
before starting the next one. OF course, we can _think_ something is
stable and then a contributor appears with insightful comments a week
or more later.
Yeah, smaller on average, but there is a long one early on. The next
eight series' patch counts are: 2, 3, 11, 7, 8, 7, 6, 7. I don't have
ones beyond that ready quite yet.
Also, for the next nine series, each one will depend upon the previous one.
quoted
* My focus for the next few series is on diffcore-rename.c, which will
also affect things other than merge-ort. While each series is
self-contained, given that 2.31-rc0 is just over 3 weeks away I'm
wondering if it makes sense to hold my future diffcore-rename series
out of 2.31 and start merging them in the 2.32 cycle. Thoughts?
It might be fine to get the code under review, but ask Junio to
delay merging into 'master' until shortly after release. This
ensures that there is plenty of time to "simmer in CI."
Makes sense; I'll submit the first one.