On 4 March 2013 18:59, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sun, Mar 3, 2013 at 9:27 PM, Josh Berkus <josh@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
