On 15/12/14 16:28, Andres Freund wrote: > I don't believe this really is a question of the type of project. I > think it's more that especially the kernel has had to deal with similar > problems at a much larger scale. And the granular approach somewhat > works for them.
Correct. My argument was that dividing patches into smaller, more reviewable chunks lessens the barrier for reviewers since many people can review the individual patches as appropriate to their area of expertise. The benefits of this are that the many parts of the patchset get reviewed early by a number of people, which reduces the workload on the core developers as they only need to focus on a small number of individual patches. Hence patches get reworked and merged much more quickly in this way. This is in contrast to the commitfest system where a single patch is i) often held until the next commitfest (where bitrot often sets in) and ii) requires the reviewer to have good knowledge all of the areas covered by the patch in order to give a meaningful review, which significantly reduces the pool of available reviewers. ATB, Mark. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
