Thread: Re: [HACKERS] Increased company involvement
Dave Held wrote: > Well, you make Postgres sound like a very democratic community, but > I'm afraid this is a fairy tale. Aren't the people who approve > patches exactly the in group that you claim doesn't exist? Aren't > they the people that you need buy-in from to really contribute to > Postgres? The reason I make this point is because I know what a > democratic development community really looks like, and the Boost > community is one such example. That truly *is* democratic, because > decisions are made as a group, and no fixed subset of members has > an overriding veto. The group has moderators, but they exist only > to moderate discussion on the mailing lists. I'm not saying that > it is bad that Postgres is not democratic. Postgres is a totally > different kind of beast than Boost, and probably benefits from > having a few people ultimately decide its fate. But let's call a > spade a spade and not pretend that contributors don't have to get > buy-in from core. Really? You have a different perspective than I see. I have seen patches be accepted that had no core buy-in. We accept patches based on group feedback, not some closed approval process. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: > Dave Held wrote: > > Well, you make Postgres sound like a very democratic community, but > > I'm afraid this is a fairy tale. Aren't the people who approve > > patches exactly the in group that you claim doesn't exist? Aren't > > they the people that you need buy-in from to really contribute to > > Postgres? The reason I make this point is because I know what a > > democratic development community really looks like, and the Boost > > community is one such example. That truly *is* democratic, because > > decisions are made as a group, and no fixed subset of members has > > an overriding veto. The group has moderators, but they exist only > > to moderate discussion on the mailing lists. I'm not saying that > > it is bad that Postgres is not democratic. Postgres is a totally > > different kind of beast than Boost, and probably benefits from > > having a few people ultimately decide its fate. But let's call a > > spade a spade and not pretend that contributors don't have to get > > buy-in from core. > > Really? You have a different perspective than I see. I have seen > patches be accepted that had no core buy-in. We accept patches based on > group feedback, not some closed approval process. Let me also ask for you to provide an example of the behavior you describe. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Mon, 2 May 2005, Bruce Momjian wrote: > Bruce Momjian wrote: >> Dave Held wrote: >>> Well, you make Postgres sound like a very democratic community, but >>> I'm afraid this is a fairy tale. Aren't the people who approve >>> patches exactly the in group that you claim doesn't exist? Aren't >>> they the people that you need buy-in from to really contribute to >>> Postgres? The reason I make this point is because I know what a >>> democratic development community really looks like, and the Boost >>> community is one such example. That truly *is* democratic, because >>> decisions are made as a group, and no fixed subset of members has >>> an overriding veto. The group has moderators, but they exist only >>> to moderate discussion on the mailing lists. I'm not saying that >>> it is bad that Postgres is not democratic. Postgres is a totally >>> different kind of beast than Boost, and probably benefits from >>> having a few people ultimately decide its fate. But let's call a >>> spade a spade and not pretend that contributors don't have to get >>> buy-in from core. >> >> Really? You have a different perspective than I see. I have seen >> patches be accepted that had no core buy-in. We accept patches based on >> group feedback, not some closed approval process. > > Let me also ask for you to provide an example of the behavior you > describe. How many patches have you "applied" thinking they were good/safe, only to have Tom jump on top of you and either require changes, or yank them completely? As far as code submissions are concerned, Tom has pretty much been "final arbitrar" (not that I'm against that, I think its required to keep the code 'clean') ... those with cvs commit privileges are a bit higher on the totem, but they've already been "through the fire" with Tom, else they would't have those privileges ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Mon, 2 May 2005, Bruce Momjian wrote: > > > Bruce Momjian wrote: > >> Dave Held wrote: > >>> Well, you make Postgres sound like a very democratic community, but > >>> I'm afraid this is a fairy tale. Aren't the people who approve > >>> patches exactly the in group that you claim doesn't exist? Aren't > >>> they the people that you need buy-in from to really contribute to > >>> Postgres? The reason I make this point is because I know what a > >>> democratic development community really looks like, and the Boost > >>> community is one such example. That truly *is* democratic, because > >>> decisions are made as a group, and no fixed subset of members has > >>> an overriding veto. The group has moderators, but they exist only > >>> to moderate discussion on the mailing lists. I'm not saying that > >>> it is bad that Postgres is not democratic. Postgres is a totally > >>> different kind of beast than Boost, and probably benefits from > >>> having a few people ultimately decide its fate. But let's call a > >>> spade a spade and not pretend that contributors don't have to get > >>> buy-in from core. > >> > >> Really? You have a different perspective than I see. I have seen > >> patches be accepted that had no core buy-in. We accept patches based on > >> group feedback, not some closed approval process. > > > > Let me also ask for you to provide an example of the behavior you > > describe. > > How many patches have you "applied" thinking they were good/safe, only to > have Tom jump on top of you and either require changes, or yank them > completely? > > As far as code submissions are concerned, Tom has pretty much been "final > arbitrar" (not that I'm against that, I think its required to keep the > code 'clean') ... those with cvs commit privileges are a bit higher on the > totem, but they've already been "through the fire" with Tom, else they > would't have those privileges ... Tom can bring up issues, but it is up to the group to decide if those are valid. Tom has sway only to the exent the group agrees with Tom's analysis. If someone else made similar observations, they would take similar weight, as soon as we were sure the person was reliable in their observations. Tom gets patches pulled only because his observations are deemed to be right by the group, not because he is Tom. The same holds for pretty much anyone else in the group. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Dave, > The group has moderators, but they exist only > to moderate discussion on the mailing lists. I'm not saying that > it is bad that Postgres is not democratic. Postgres is a totally > different kind of beast than Boost, and probably benefits from > having a few people ultimately decide its fate. But let's call a > spade a spade and not pretend that contributors don't have to get > buy-in from core. Hmmm ... why does everyone assume that Core does more than what we do? I think that most people would be surprised by how *little* traffic there is on the pgsql-core mailing list. Core decides on releases, and approves committers. Occasionally we'll handle something which requires confidentiality, like a security issue or a new corporate participant. The committers, who do *not* have exact overlap with Core (for example, Neil is a committer but not on Core, and I am on Core but not a committer) actually commit patches, so the participation of *one* of them is required to get something in to the core code. Materially, what's accepted is decided through open discussion on the pgsql-hackers list; even Tom brings up his patches for discussion before commit, and I'd defy you to point to even one patch which was accepted by consensus on pgsql-hackers and not committed. As you've already observed, if Tom doesn't like something it's very unlikely to get through. But that's true for a lot of major contributors; the consensus process we use provides ample opportunities to veto and slender opportunities to pass. Go back in the archives to 7.4 development, and you will see Peter exercising his veto a lot, rather than Tom -- and Peter was not a Core team member at the time. From my perspective, this is a good thing for a database system which can get easily broken by an ill-considered patch. It's *good* for us to be development-conservative. So there is an "insider group", but it's the group of major contributors. Tom has the loudest voice because he writes the most code. The fact that Tom, Bruce or Peter's veto is often as far as a proposal goes is simply because most of the pgsql-hackers subscribers simply don't involve themselves in the process unless it's one of their own pet features. And the important thing about the group of major contributors is that membership is open. This goes beyond new proposals. Just the other day Bruce was lamenting the fact that despite having a number of committers, nobody other than him seems willing to work out the conflicts and get pending patches into acceptable shape for backend integration -- some patches stayed in the queue for months while he was out. This is bad; it bottlenecks us and makes Bruce and Tom the de-facto arbiters of acceptance because they personally have to adjust and commit submissions. If people want the acceptance process to be more "democratic", then those people have to be willing to do the work of full participation. This means arguing and doing research on the hackers list, even for proposals that don't personally benefit you; helping debug and/or test patches to get rid of their problems; and ultimately, becoming a major contributor and then a committer yourself so that you can take over part of Bruce's workload. When this system has broken down it's specifically because people on the -hackers list were lazy or distracted and ignored other people's patch proposals, allowing one member's (whether Tom or anyone else) reflexive veto to stand without challenge. And by failing to champion the usefulness of proposals. I know that some of Joe's proposals were unfairly killed simply because nobody on -hackers spoke up for them, leading Tom and others to believe that they weren't popular or needed. Personally, I tend to think that one of the several things fundamentally broken in the US electoral system is that there is no relationship between political participation, voting, and authority. I don't see any reason to replicate those mistakes with our project. So if your definition of "democracy" is "everyone has an equal voice regardless of participation level", then thank the gods we're not a "democracy". (P.S. on a complete tangent, "call a spade a spade" is actually a racist expression originating in the reconstruction-era South. "spade" does not mean garden tool but is a derogatory slang term for black people. It's an expression I avoid for that reason. I don't expect anyone to have known this, but now you do.) -- --Josh Josh Berkus Aglio Database Solutions San Francisco
On Mon, 2 May 2005, Josh Berkus wrote: > As you've already observed, if Tom doesn't like something it's very unlikely > to get through. One thing to note on this one ... I've never seen Tom *not* try and help the submitter to get the code up to spec either ... he's always bent over backwards to try and help set someone on the right path if the patch submission warrants it ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Mon, 2 May 2005, Josh Berkus wrote: > >> As you've already observed, if Tom doesn't like something it's very >> unlikely >> to get through. > > > One thing to note on this one ... I've never seen Tom *not* try and help > the submitter to get the code up to spec either ... he's always bent > over backwards to try and help set someone on the right path if the > patch submission warrants it ... I would second this. Even when he has disagreed he is always willing to say why and even offer guidance to sway him. Sincerely, Joshua D. Drake Command Prompt, Inc. > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Josh Berkus <josh@agliodbs.com> writes:
> As you've already observed, if Tom doesn't like something it's very unlikely
> to get through.
I lose my share of arguments --- in fact, in the twenty minutes since
your posting I already notice Bruce committing a patch I had objected to
;-).
Our process is not "democratic" in the sense of any random subscriber to
the mailing lists having the same vote as a core member --- and I'll bet
Boost doesn't run things that way either. What we have is pretty
informal but I think it effectively gives more weight to the opinions of
those more involved in the project; which seems a good way to operate.
But there isn't anyone here who has an absolute veto, nor contrarily
anyone who can force things in unilaterally over strong objections.
> [ much good commentary snipped ]
regards, tom lane
Tom Lane wrote: > Josh Berkus <josh@agliodbs.com> writes: > > As you've already observed, if Tom doesn't like something it's very unlikely > > to get through. > > I lose my share of arguments --- in fact, in the twenty minutes since > your posting I already notice Bruce committing a patch I had objected to > ;-). I replied to your concerns on Saturday night, and when I saw no community response by noon today, I assume everyone as OK and applied it. I suppose this is as good an illustration of the process as we are going to get. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073