Re: Formatting Curmudgeons WAS: MMAP Buffers

On the big picture of scheduling issues, I have never seen a major piece 
of software ship every 6 months without being incredibly buggy.  I'd 
lose serious faith in this project if that happens here.  Since I've 
never seen a major operating system ship usefully more than about once 
every two years, so I'm not sure who it would be serving anyway.  Even 
if this project pulled it off, those who would see the benefit because 
they're using things like the upgrade-happy Ubuntu/Fedora/Gentoo 
treadmills are clearly not optimizing for the sort of things database 
users care about anyway.  So whacking around the low-level schedule to 
aim at that goal boggles my mind.

As for trying to improve things within the existing yearly cycle, there 
are several types of patch to be concerned about here.  And the useful 
interval to respond isn't the same for all of them.

This discussion started with "newbie patch".  I'd like to see these get 
a review sufficient to say "you're not following the good practices 
outlined by our code guidelines and we can't do anything with this" 
quickly, with a hand-off to resources to help them with that.  Everyone 
reading this list surely knows where that documentation is at now after 
all this publicity.  You might schedule a weekly "answer the newbies" 
scan usefully to help with this.  But the project doesn't get much out 
of that besides being more friendly and encouraging, to help in the 
growing the community long-term.  In the short term, adding more process 
here just to help these submitters will, pragmatically, mainly get in 
the way of working on more finished patches.

Second is "WIP", where the author knows there are issues but is looking 
for feedback.  In the cases where these are interesting to people, these 
sometimes get immediate feedback too.  The ones that don't are because 
a) it's hard to review, or b) no one else is interested enough to poke 
at it immediately.  That means a reviewer will likely need to be either 
assigned or found & motivated to look for it.  And that's painful enough 
that you don't want to do it regularly.  The overhead of herding patch 
reviewers is seriously underestimated by some of the ideas throw around 
here for reducing the intervals of this process.  It's only reasonable 
to do in bulk, where you can at least yelp on-list to try and get 
volunteers usefully.

[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.]

Next up is "solid patch that needs technical review".  This is mainly 
different from the WIP case in that it's unlikely any quick feedback 
will help the submitter.  So here it's back to needing to find a 
reviewer again.

Finally, "big feature patch", likely taking multiple CFs to process.  
It's barely possible to get useful feedback on these every two months.   
I don't see how dropping the interval is going to solve any of the 
problems around these.  Two to three people all need to get aligned for 
progress on these to happen:  the author, a reviewer, and a committer, 
with the commiter sometimes also doing the initial review.  Good luck 
making that happen more often than it already does.

I think that anyone who suggests shortening the cycles here, or making 
the CommitFests more frequent, should volunteer to run one.  That will 
beat the idea right out of you.  Work on the problem of how to 
motivate/create more patch reviewers instead; that's where the actual 
bottleneck in this process is at.  Part of the problem with how newbies 
are handled is that they jump right to writing patches, because that's 
cooler to do, rather than starting with doing review.  That's 
counterproductive--best way to learn how to write a good patch is to 
consider the difficulty someone else faces reading one--but you can't 
tell that to some people usefully.

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.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us