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 g...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
