On Thu, Nov 30, 2023 at 02:39:41PM -0500, Taylor Blau wrote:
> On Thu, Nov 30, 2023 at 11:18:19AM +0100, Patrick Steinhardt wrote:
[snip]
> Then you'd have five patch series, where each series does roughly the
> following:
>
> 1. Preparatory clean-up.
> 2. Implementing the DISP chunk, as well as --retain-disjoint, without
> a way to generate such packs.
> 3. Implement a way to generate such packs, but without actually being
> able to reuse more than one of them.
> 4. Implement multi-pack reuse, but without actually reusing any packs.
> 5. Enable multi-pack reuse (and implement the required scaffolding to
> do so), and test it.
>
> That's the most sensible split that I could come up with, at least.
Looks sensible to me.
> 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:
- Contributors may go away in the middle of their endeavour, leaving
behind dangling pieces that might have complicated some of our
architecture without actually reaping the intended benefits.
- Overall, it may take significantly longer to get all pieces into
Git.
- Contributors need to do a much better job to explain where they are
headed when the series by itself doesn't do anything interesting
yet.
So I understand why we typically don't work this way.
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.
> - 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.
Patrick
Attachment:
signature.asc
Description: PGP signature
