Re: Additional options for Sync Replication

On Tue, Mar 29, 2011 at 10:48 AM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> So the rules are not the same for commiter patches and contributor
> patches, and there's no good in trying to have them the same or
> pretending they are.  In particular, only commiters are able to finish
> and polish the work between the last commit fest and beta, and then they
> will be on the hook to get to release candidate and release.
>
> But you know all that better than I do.

Committers can and do get away with slipping things in later than
non-committers, and to some extent that's OK for the reasons you
mention. But Alvaro was very gracious in conceding that it was a bit
too late to push in his key lock patch, as was his employer, JD. They
didn't like it, but they accepted that it was necessary to move the
community, overall, forward, and to avoid a really long beta period
during which, really, nobody gets to do anything at all interesting.
We cannot have one standard for features that CommandPrompt really
wants committed and a different standard for features that 2ndQuadrant
or, say, EnterpriseDB, really want committed.

I completely disagree that committers are the only ones who can finish
and polish work between the last CommiFest and beta. Fujii Masao,
Kevin Grittner, Yeb Havinga, and Yamamoto Takashi all come to mind as
people who have been very, very helpful in moving us toward beta
through careful testing and code review. I have no fear at all about
our ability to maintain SSI even though there is not one committer who
fully understands it all, because every bug report that comes in gets
a response within hours and a patch within days. The limiting factor
there has actually been how long it's taken someone to look and test
those patches, not how quickly they've been produced. I think the
reality is exactly the other way around: committers are not the people
who get the opportunity to fix other people's bugs; they are the
people who are *expected* to fix other people's bugs when no one else
will. If it's your perception that the (mostly quite minor) changes
that I've made to sync rep are somehow for purposes of
self-aggrandizement or a desire to micromanage everything that happens
in the backend, then I'm sorry for that. I'll readily admit that I
have strong opinions on lots of topics, especially but not only
PostgreSQL-related topics; but I would be way happier to have spent
the last couple of weeks developing new features than swatting bugs.
Had I done that, though, I think that not as many bugs would have
gotten swatted. So I did it. Whether that makes me a helpful
community guy who tries to ensure a quality release or a total jerk
who interjects his nose into other people's business is, of course, a
matter of opinion.

Even today, anyone who would like to write a patch to address more
than one of the open items is more than welcome to do so, and I would
really appreciate it, even I or someone else ends up having to adjust
it a bit before committing. There are at least three issues on the
open items list that are obvious candidates for someone to pick up:

- fix attinhcount tracking
- Typed-tables patch broke pg_upgrade
- comments on SQL/MED objects

I volunteered to pick up the last one, but I'd be more than happy if
the person who reported the problem had already provided the patch.
Or if someone else wanted to write the patch. That would be awesome.
In my view, the question we should be asking ourselves here is not -
why are Tom and Robert getting to make all these commits? - but -
where is everybody else who should be helping out? If the answer is
"well we don't have time to work on this because we all have day jobs
we have to do to get paid", then I accept that. But that moves
getting to commit changes at a late date from the "privilege" bucket
into the "responsibility" bucket.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company