Greg Smith wrote:
> [There were complaints upthread about things like how Aster's patch
> submissions were treated. Those were WIP patches that half implemented
> some useful ideas. But they were presented as completed features, and
> they seemed to expect the community would pick those up and commit in
> that not quite right state without extended additional work on their
> side. Not doing that sort of thing is part of the reason the PostgreSQL
> code isn't filled with nothing but the fastest hack to get any given job
> done. Anyone who thinks I'm misrepresenting that view of history should
> revisit the lengthy feedback provided to them at
> https://commitfest.postgresql.org/action/patch_view?id=173 and
> https://commitfest.postgresql.org/action/patch_view?id=205 -- it
> actually goes back even further than that because the first versions of
> these patches were even less suitable for commit.]
[ Again, sorry for my late reply.]
Greg hits a big item above --- it takes 3-4x more work to get a patch to
merge cleanly into our code ("look like it was always there") than to
write the initial patch. If the author isn't willing to do that 3-4x
work, it is not something the community is going to do on a regular
basis, so it is not surprising the patches are dropped. This is very
often true of academicly-developed patches too. (I know I rewrite my
patches 4-5 times, and some feel even that is not enough interations for
me. ;-) )
> That goes double for some of the people complaining in this thread about
> dissatisfaction with the current process. If you're not helping review
> patches already, you're not participating in the thing that needs the
> most help. This is not a problem you make better with fuzzy management
> directives to be nicer to people. There are real software engineering
> issues about how to ensure good code quality at its core.
I agree on this one too. It is good for people outside the patch review
group to make suggestions (external review is good), but when those
external people can't give clear examples of problems, it is impossible
for the patch review group to react or improve, and the complaints do
more harm than good. The complaints did spark discussion to reevaluate
our development process, so something good did come out of it.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
