On 4 March 2013 18:59, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sun, Mar 3, 2013 at 9:27 PM, Josh Berkus <j...@agliodbs.com> wrote: >>> Except that the implication of "waiting on author" is that, if there's >>> no updates in a couple weeks, we bounce it. And the author doesn't >>> necessarily control a bikeshedding discussion about syntax, for example. > >> That's true. I think, though, that the basic problem is that we've >> lost track of the ostensible purpose of a CommitFest, which is to >> commit the patches that *are already ready* for commit. > > Mumble. That's *part* of the purpose of a CF, but not all. It's also > meant to be a time when people concentrate on reviewing patches, and > surely discussions about syntax or whatever have to be part of that. > > I recall in fact that at the last developer meeting, there was > discussion about trying to get people to do more formal reviewing of > design ideas that hadn't even made it to the submittable-patch stage. > So I feel it's counterproductive to try to narrow the concept of a CF > to "only ready to commit" patches.
Agreed. "Ready to commit" is a state, and everybody has a different view of the state of each patch. So we need a point where we all sync up and decide by some mechanism what the group's opinion of the state is and handle accordingly. Or put another way, I very much welcome the chance for feedback from others on my work, and appreciate the opportunity for review of others work. If we can commit at any time, then every discussion needs to be followed in detail otherwise we get "you should have said that earlier" repeatedly. By all stopping, having a cup of tea and deciding what we're happy with and then continue, it gives the opportunity for efficient thread scheduling of our work. Between CFs we can work mostly independently. People starting new discussions while we have a big patch queue is annoying, because it just makes the whole queue slow down and even less gets done in the long run. We need to look at good overall thruput, not continually interrupt each other, causing single threading and overall loss of efficiency. Same idea as if we had a meeting, it would be cool if everybody listened to the meeting, not took calls and then walked back in and repeat discussions that already happened. And overall, one long rolling discussion on hackers is the same thing as saying all developers spend all day every day in a meeting - we should recognise how unproductive that is and work out ways to avoid it. Process changes every year because the skills, capacities and requirements change each year. So change doesn't imply last thing was broken. The general question is how can we work efficiently together and still produce high quality software? > But having said that, maybe the last CF of a cycle has to be treated > more nearly as you suggest. Certainly if we hold off ending the CF > in hopes of committing stuff that wasn't nearly ready to commit at > its beginning, then we're back to bad old habits that seldom lead > to anything but a late release. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
