Re: [HACKERS] Increased company involvement - Mailing list pgsql-advocacy

> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> Sent: Monday, May 02, 2005 12:17 PM
> To: PostgreSQL advocacy
> Cc: Dave Held; PostgreSQL-development
> Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement
>
> > [...]
> > 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.

Well, I think there's numerous examples where someone suggests some
feature or idea, and Tom or one or two other core developers will
say: "I don't like that idea", and then the proposer will more or
less give up on it because it is clear that it won't go anywhere.
So whether the process gets stopped at the patch submission level
or the feature proposal level isn't really relevant.  It seems pretty
clear that a handful of people decide the direction of Postgres,
and everyone else can either contribute to the features that have
been agreed to be acceptable and relevant, or they can fork their
own version.

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
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.

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.

__
David B. Held
Software Engineer/Array Services Group
200 14th Ave. East,  Sartell, MN 56377
320.534.3637 320.253.7800 800.752.8129