Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
> -Original Message- > From: Andrew Dunstan [mailto:[EMAIL PROTECTED] > Sent: Monday, May 02, 2005 7:05 PM > To: [EMAIL PROTECTED] > Cc: Dave Held; [EMAIL PROTECTED]; > pgsql-hackers@postgresql.org > Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: > Increased > company involvement > > [...] > I nat happy avout that last point - personally, I value most > highly the views of those who contribute code or similar and > least highly the views of those whose principal contribution > is opinions. Maybe so, but if you were a new contributor, why would you write a bunch of code with no assurance that it would go anywhere? It seems wiser to invest your time familiarizing yourself with the ins and outs of the codebase and the coding style of patches by looking at other people's work. It also seems smarter to lurk and see what kinds of changes are likely to be considered. I doubt you would think highly of a newcomer that contributed code that was not in the style of the codebase and was for a feature not on the TODO list and that didn't get community buy-in first. But then, how do you get community buy-in if you don't contribute code, according to you? __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
Robert Treat said: >> * Engage the community by participating in discussions and patch >> reviews - your credibility as a contributor depends on your >> willingness to contribute to the community in non-coding >> ways as well > > Actually I think Bruces blurb is good for the general FAQ, and this > would be good for the Developer FAQs > I nat happy avout that last point - personally, I value most highly the views of those who contribute code or similar and least highly the views of those whose principal contribution is opinions. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
On Monday 02 May 2005 17:32, Dave Held wrote:
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> > Sent: Monday, May 02, 2005 3:33 PM
> > To: Dave Held
> > Cc: PostgreSQL advocacy; PostgreSQL-development
> > Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS:
> > Increased
> > company involvement
> >
> > [...]
> > Here is a new FAQ entry:
> >
> > 1.13) Who controls PostgreSQL?
> >
> > If you are looking for a PostgreSQL gatekeeper,
> > central committee, or controlling company, give up, because
> > none exists. We do have a core committee and CVS committers,
> > but these groups are more for administrative purposes then
> > control. The project is directed by the open community of
> > developers and users of PostgreSQL. Everyone is welcome to
> > subscribe and take part in the discussions. (See the
> > http://www.postgresql.org/docs/faqs.FAQ_DEV.html";>
> > Developer's FAQ for information on how to get
> > involved in PostgreSQL development.)
> >
> > Adjustments?
>
> "...are more for administrative purposes [then->than] control..."
>
> Because PostgreSQL is a monolithic product, all of its features
> must work together in tight harmony. It is in the interests of
> the PostgreSQL community that new features be integrated in a way
> that preserves this harmony. Thus, new feature proposals are
> scrutinized and debated by the community to ensure that changes
> have sufficient technical merit. Be prepared to defend your
> proposal, and don't assume that a privately developed contribution
> will automatically be accepted by the PostgreSQL community. To
> maximize the chance of success in proposing a change, consider
> these suggestions:
>
> * Propose your change/feature publicly - OSS is about community,
> and a collection of contributors working independently without
> communication is not a community; this avoids duplication of
> effort and promotes collaboration/cooperation among parties
> that have a common interest
> * Research your proposal to see if it has already been discussed
> on the mailing list
> * Research your proposed solution to make sure it is the best of
> breed - database technology is a very active subject of
> academic research, and it is possible, if not likely, that
> someone has written a paper on the topic
> * Engage the community by participating in discussions and patch
> reviews - your credibility as a contributor depends on your
> willingness to contribute to the community in non-coding
> ways as well
>
>
> I realize that this runs a bit far afield from the original
> question of "Who controls PostgreSQL?", but I think it addresses
> the points that someone who asks this question is likely to
> want to know. It also tackles the contribution question from
> a higher level than the dev-faq.
Actually I think Bruces blurb is good for the general FAQ, and this would be
good for the Developer FAQs
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: Monday, May 02, 2005 1:50 PM > To: josh@agliodbs.com > Cc: Bruce Momjian; Marc G. Fournier; PostgreSQL advocacy; Dave Held; > PostgreSQL-development > Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: > Increased > company involvement > > > [...] > 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. Actually, it does, but it can afford to for very special reasons. Because Boost is not about a single problem domain, there is no real "core" of developers. There are some who have contributed more libraries, or larger libraries; but at the end of the day, each review and submission is judged on its own merits. Often, the person submitting a new library for review is a domain expert for that library; and people reviewing a library are also often domain experts, even if they are a first-time reviewer. So the very nature of Boost allows it to be more democratic. Because Postgres is about a single problem domain, and because each submission must work in concert with an extant whole, it has totally different needs and a totally different type of community. And because a database isn't exactly a modular beast like, say, a web server, that limits the openness of the community further. That is to say, there is a barrier to entry, but it isn't capriciously imposed by the community members. It's just a necessary outcome of the nature of the project. People who want to contribute should understand this barrier and how it works before they start writing code. > 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. For Postgres, I agree. > But there isn't anyone here who has an absolute veto, nor > contrarily anyone who can force things in unilaterally over > strong objections. Nor would one expect such a thing in a project that claims to be OSS. But ultimately persuasion is as much a part of consensus as merit, and people should recognize that fact when contributing to the project. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
> -Original Message- > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > Sent: Monday, May 02, 2005 3:33 PM > To: Dave Held > Cc: PostgreSQL advocacy; PostgreSQL-development > Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: > Increased > company involvement > > [...] > Here is a new FAQ entry: > > 1.13) Who controls PostgreSQL? > > If you are looking for a PostgreSQL gatekeeper, > central committee, or controlling company, give up, because > none exists. We do have a core committee and CVS committers, > but these groups are more for administrative purposes then > control. The project is directed by the open community of > developers and users of PostgreSQL. Everyone is welcome to > subscribe and take part in the discussions. (See the > http://www.postgresql.org/docs/faqs.FAQ_DEV.html";> > Developer's FAQ for information on how to get > involved in PostgreSQL development.) > > Adjustments? "...are more for administrative purposes [then->than] control..." Because PostgreSQL is a monolithic product, all of its features must work together in tight harmony. It is in the interests of the PostgreSQL community that new features be integrated in a way that preserves this harmony. Thus, new feature proposals are scrutinized and debated by the community to ensure that changes have sufficient technical merit. Be prepared to defend your proposal, and don't assume that a privately developed contribution will automatically be accepted by the PostgreSQL community. To maximize the chance of success in proposing a change, consider these suggestions: * Propose your change/feature publicly - OSS is about community, and a collection of contributors working independently without communication is not a community; this avoids duplication of effort and promotes collaboration/cooperation among parties that have a common interest * Research your proposal to see if it has already been discussed on the mailing list * Research your proposed solution to make sure it is the best of breed - database technology is a very active subject of academic research, and it is possible, if not likely, that someone has written a paper on the topic * Engage the community by participating in discussions and patch reviews - your credibility as a contributor depends on your willingness to contribute to the community in non-coding ways as well I realize that this runs a bit far afield from the original question of "Who controls PostgreSQL?", but I think it addresses the points that someone who asks this question is likely to want to know. It also tackles the contribution question from a higher level than the dev-faq. Obviously, the bullet points would be formatted as a list or some other appropriate HTML construct. And as a minor point, it would be nice if the website validated to XHTML-strict, although XHTML-transitional would be a good compromise. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
On Monday 02 May 2005 14:49, Josh Berkus wrote:
> Bruce,
>
> > > (P.S. on a complete tangent, "call a spade a spade" is actually a
> > > racist expression originating in the reconstruction-era South.
> > > "spade" does
> >
> > You must be from California. :-)
>
> Well, yes. Actually, from San Francisco, which is even worse.And I
> just spent the weekend in Orange County which really gotten my PC dander
> up. Sorry, Dave!
And this is why I hate the PC movement... The phrase calling a spade a spade
pre-dates the U.S. as whole, much less the reconstruction-era South. It is
believed to have been introduced into the english language via John Knox in
the 1500's who wrote "I have learned to call wickedness by its own terms: A
fig, a fig, and a spade a spade", borrowing from an earlier latin text, which
is believed to be based on an even earlier Greek writer.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
Dave, > Well, I never said that core runs around saving the world. I > mostly made the point that core developers have special > influence, Yep. Absolutely. I wanted to point out to you that core isn't the only group within PostgreSQL that has special influence. > Which is also something that new would-be corporate > contributors should know about. Yes. All of this would be worthy of a FAQ somewhere. Up for it? > It is bad if the person > making the proposal doesn't feel he/she has good odds in > defending the proposal and gives up without a fight. Yes.Again, I think a FAQ would help. If people are prepared for the idea of defending their ideas, then they're less likely to quit as soon as someone says "no". > My point is that it's not *democratic*, > and that outsiders wishing to contribute should understand > the dynamic of the process that is not explicitly and officially > spelled out anywhere. Hmmm. We'll there's two (or more) uses of the word "democratic"; so I think there's considerable confusion resulting. In the sense of "democratic" meaning "maximizing the participation and authority of all project members", we are "democratic". In the sense of "one person, one vote", we are not. Classically, our structure could be described as "anarchistic" -- in the 1890's definition, not the modern one. > Right. I agree. I'm not criticising the process as a whole, > and I've more or less made this exact point myself. Yes. I'm not responding just to you, btw. I'm responding to a number of comments from other people who erroneously see Core as exercising more authority than we actually do. > Which may be true philosophically, but in practice, most people > who contribute will not have the resources or motivation to > become a major contributor. I do not mean to imply that this > is necessarily a bad thing; but I think it is the true state of > affairs, and part of the dynamic which must be understood by > someone considering investing in Postgres as a contributor. Certainly. Although the decision-making process for acceptance is really of interest primarily for contributors; that is, if you are not submitting, even by proxy, it shouldn't really matter to you how stuff gets accepted. Except to the extent that you *should* jump in and advocate for proposals by others which you like so that the contributors, committers, and core know what people care about. > That actually doesn't make it more democratic. In a democracy, > everyone has an equal vote regardless of their status. The point > is that a democracy is not always a priori the best form of > organization. Certainly. See above. > What you describe is actually a meritocracy, > and for a project like Postgres, it makes a lot of sense. Hmmm ... I dislike the word "meritocracy" because it is applied equally to corporations, where regardless of merit you're never going to be on the Board. > But > that merely reinforces my point that contributors need to > understand that if their pet feature they create is not in line > with core thinking, they will have to earn the credibility to > get community buy-in. Substitute "major contributors" for "core", and you have *my* buy-in. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
Josh Berkus 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
Bruce, > > (P.S. on a complete tangent, "call a spade a spade" is actually a racist > > expression originating in the reconstruction-era South. "spade" does > > You must be from California. :-) Well, yes. Actually, from San Francisco, which is even worse.And I just spent the weekend in Orange County which really gotten my PC dander up. Sorry, Dave! -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
> -Original Message- > From: Josh Berkus [mailto:[EMAIL PROTECTED] > Sent: Monday, May 02, 2005 1:21 PM > To: Bruce Momjian > Cc: Marc G. Fournier; PostgreSQL advocacy; Dave Held; > PostgreSQL-development > Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: > Increased > company involvement > > [...] > 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. Well, I never said that core runs around saving the world. I mostly made the point that core developers have special influence, and that should be considered when contributing to Postgres, which is directly relevant to the point of the thread, which was originally called "Increased company involvement." > Core decides on releases, and approves committers. > Occasionally we'll handle something which requires > confidentiality, like a security issue or a new > corporate participant. Which is also something that new would-be corporate contributors should know about. > [...] > 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. But this misses the point. The point is that consensus is often an iterative process, and even if a few people support an idea at first, in the end, the weight of a few "inner circle" people (whether they be core or patch approvers or whatnot) tends to sway the consensus in a certain direction. This isn't always bad, especially if those core people simply know more about the internals of Postgres to have better judgement. It is bad if the person making the proposal doesn't feel he/she has good odds in defending the proposal and gives up without a fight. > 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. This also misses another point. I'm not saying that the current process is inherently flawed. It's probably about as good as any OSS project. My point is that it's not *democratic*, and that outsiders wishing to contribute should understand the dynamic of the process that is not explicitly and officially spelled out anywhere. > [...] > 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. Right. I agree. I'm not criticising the process as a whole, and I've more or less made this exact point myself. > So there is an "insider group", but it's the group of major > contributors. That is exactly my point, but you said it better. > 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. Which is perfectly understandable. You can probaby guess that most people who use Postgres haven't tried to implement an RDBMS themselves, and have only a shallow understanding of the details. > And the important thing about the group of major contributors > is that membership is open. Which may be true philosophically, but in practice, most people who contribute will not have the resources or motivation to become a major contributor. I do not mean to imply that this is necessarily a bad thing; but I think it is the true state of affairs, and part of the dynamic which must be understood by someone considering investing in Postgres as a contributor. > [...] > If people want the acceptance process to be more "democratic", > then those people have to be willing to do the work of full > participation. That actually doesn't make it more democratic. In a democracy, everyone has an equal vote regardless of their status. The point is that a democracy is not always a priori the best form of organization. What you describe is actually a meritocracy, and for a project like Postgres, it makes a lot of sense. But that merely reinforces my point that contributors need to understand that if their pet feature they create is not in line with core thinking, they will have to earn the credibility to get community buy-in. > [...] > (P.S. on a complete tangent, "call a spade a spade" is > actually a racis
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
