Re: Additional options for Sync Replication
От | Robert Haas |
---|---|
Тема | Re: Additional options for Sync Replication |
Дата | |
Msg-id | AANLkTimTz6YYBAY3Lz=_1CjXZq2M78s9AjvQPPnGkFzQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Additional options for Sync Replication (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Ответы |
Re: Additional options for Sync Replication
|
Список | pgsql-hackers |
On Tue, Mar 29, 2011 at 10:48 AM, Dimitri Fontaine <dimitri@2ndquadrant.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
В списке pgsql-hackers по дате отправления: