Re: [HACKERS] Increased company involvement

As someone who has made a few minor contributions and plenty of
suggestions, but who is not on the core team, I would like to offer my
observations.

Every suggestion I have ever made that had any merit at all has
eventually worked its way into PostgreSQL (most -- perhaps all -- were
already under consideration).

The dumb ideas I coughed up were neatly shot down in flames as they
should have been.

The PostgreSQL project is very well run, in fact amazingly well
considering the loose structure of an open source project.

There are a few things that might be accomplished a bit differently, but
I do not know how it would be possible to architect it (for instance, I
would completely divorce the testing team from the development team
since that is how it is usually done with commercial systems).

IMO-YMMV.

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-
> owner(at)postgresql(dot)org] On Behalf Of Bruce Momjian
> Sent: Monday, May 02, 2005 10:56 AM
> To: Dave Held
> Cc: PostgreSQL-development; PostgreSQL advocacy
> Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement
>
> Dave Held wrote:
> > Just watching the hackers list suggests to me that this is the norm,
> > rather than the exception. I guess I'm interested to see which
> > patches have been accepted that the core developers opposed. Now
> > don't get me wrong. Sometimes there are good technical reasons why
> > feature A or B can't or shouldn't be added or even developed. And
> > I don't suggest that patches lacking technical merit should not be
> > rejected. But sometimes it seems that ideas with undetermined
> > merit get passed over because of a quick judgement based on
> > intuition, and only if the proposer actively fights for it for a
> > while does it get reconsidered.
> >
> > Of course, it would be quite a bit of work for me to review the
> > list and compile instances where I think this has occurred, but
> > only because of the tedium involved to make a minor point...not
> > because I think I would have difficulty finding evidence. I'm just
>
> Well, if there was an issue and you had been around for a minimal
amount
> of time, I would think you could come up with at least one example.
>
> > saying that as an outsider, if I had a lot of resources to devote
> > to contributing to Postgres, I would only consider working on
> > approved TODO items or making sure I more or less had core buy-in
> > before writing any code. I don't think it would be worth my
> > time to work on something that non-core users/developers might
> > like but core hackers don't.
>
> Well, our developer's FAQ clearly states you should communicate your
> ideas to the hackers list before starting work to be sure you have
> _community_ buy-in, rather than core buy-in.
>
> And the TODO list is not a core list, it is accumulated from community
> suggestions and discussion.
>
> > Like I said, that's not necessarily a bad thing. Postgres is a
> > piece of software with many interacting components, and there
> > needs to be some coordination to make sure it evolves in a
> > sensible way. But I think that implies that there must be and
> > is some de facto centralization of control, whether that is the
> > published ideology or not.
>
> I will give you the example of adding a read-only table as an example.
I
> am betting the idea will not be accepted because the costs outweight
the
> gain, but I will post my opinions on the list and others will as well
> and we will come to some concensus. If X members feel something is
bad,
> and 5X members think something is good, it almost always gets in ---
it
> doesn't matter if all the core people are in X or not.
>
> Another example is the recent patch to check if there are orphaned
file
> system files. That was submitted, Tom had questions, I posted why I
> thought it was valid, and the patch is going in today. Anyone has the
> ability to argue their point and try to sway the community, and any
> member has the right to request a vote on a specific issue.
>
> Perhaps we are more a replublic because we do defer our judgement to
> others who have looked into the area more thoroughly.
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania
> 19073
>
> ---------------------------(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