On 20/05/2024 02:09, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>> On Sun, May 19, 2024 at 03:18:11PM -0400, Tom Lane wrote:
>>> * Another reason for things sitting a long time is that they're too
>>> big to review without an unreasonable amount of effort. We should
>>> encourage authors to break large patches into smaller stepwise
>>> refinements. It may seem like that will result in taking forever
>>> to reach the end goal, but dropping a huge patchset on the community
>>> isn't going to give speedy results either.
>
>> I think it is sometimes hard to incrementally apply patches if the
>> long-term goal isn't agreed or know to be achievable.
>
> True. The value of the earlier patches in the series can be unclear
> if you don't understand what the end goal is. But I think people
> could post a "road map" of how they intend a patch series to go.
>
> Another way of looking at this is that sometimes people do post large
> chunks of work in long many-patch sets, but we tend to look at the
> whole series as something to review and commit as one (or I do, at
> least). We should be more willing to bite off and push the earlier
> patches in such a series even when the later ones aren't entirely
> done.
[resend due to DKIM header failure]
Right. As an observation from someone who used to dabble in PostgreSQL internals a
number of years ago (and who now spends a lot of time working on other well-known
projects), this is something that really stands out with the current PostgreSQL workflow.
In general you find that a series consists of 2 parts: 1) a set of refactorings to
enable a new feature and 2) the new feature itself. Even if the details of 2) are
still under discussion, often it is possible to merge 1) fairly quickly which also
has the knock-on effect of reducing the size of later iterations of the series. This
also helps with new contributors since having parts of the series merged sooner helps
them feel valued and helps to provide immediate feedback.
The other issue I mentioned last time this discussion arose is that I really miss the
standard email-based git workflow for PostgreSQL: writing a versioned cover letter
helps reviewers as the summary provides a list of changes since the last iteration,
and having separate emails with a PATCH prefix allows patches to be located quickly.
Finally as a reviewer I find that having contributors use git format-patch and
send-email makes it easier for me to contribute, since I can simply hit "Reply" and
add in-line comments for the parts of the patch I feel I can review. At the moment I
have to locate the emails that contain patches and save the attachments before I can
even get to starting the review process, making the initial review barrier that
little bit higher.
ATB,
Mark.