Re: [PATCH 00/24] pack-objects: multi-pack verbatim reuse

From: Taylor Blau <me@ttaylorr.com>
Date: Dec 1, 2023, 20:02 UTC
Message-ID: <ZWo7zjs+q8SZ5o1o@nand.local>
In-Reply-To: <ZWmZ0pk6fr-8dmF1@tanuki>

On Fri, Dec 01, 2023 at 09:31:14AM +0100, Patrick Steinhardt wrote:

Show 17 quoted lines

> > But
> > I still find it relatively unsatisfying for a couple of reasons:
> >
> >   - With the exception of the last group of patches, none of the earlier
> >     series enable any new, useful behavior on their own. IOW, if we just
> >     merged the first three series and then forgot about this topic, we
> >     wouldn't have done anything useful ;-).
>
> Well, sometimes I wish we'd buy more into the iterative style of working
> in the Git project, where it's fine to land patch series that only work
> into the direction of a specific topic but don't yet do anything
> interesting by themselves. The benefits would be both that individual
> pieces land faster while also ensuring that the review load is kept at
> bay.
>
> But there's of course also downsides to this, especially in an open
> source project like Git:

I tend to agree with the downsides you list. My biggest concern with this series in particular is that we're trying to break down an all-or-nothing change into smaller components. So if we landed four out of the five of those series, it would be better to have landed none of them, since the first four aren't really all that useful on their own.

I suppose if we're relatively confident that the last series will be merged eventually, then that seems like less of a concern. But I'm not sure that we're at that point yet.

Show 5 quoted lines

> I wonder whether a compromise would be to continue sending complete
> patch series, but explicitly point out "break points" in your patch
> series. These break points could be an indicator to the maintainer that
> it's fine to merge everything up to it while still keeping out the
> remainder of the patch series.

I think that's a reasonable alternative. It does create a minor headache for the maintainer[^1], though, so I'd like to avoid it if possible.

Show 8 quoted lines

> >   - The fourth series (which actually implements multi-pack reuse) still
> >     remains the most complicated, and would likely be the most difficult
> >     to review. So I think you'd still have one difficult series to
> >     review, plus four other series which are slightly less difficult to
> >     review ;-).
>
> That's fine in my opinion, there's no surprise here that a complicated
> topic is demanding for both the author and the reviewer.

My preference is to avoid splitting the series if we can help it. But if you feel strongly, or others feel similarly, I'm happy to take another crack at breaking it up. Thanks for all of your review so far!

Thanks, Taylor