Re: Contributing code

From: Don Y <pgsql(at)DakotaCom(dot)Net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: Contributing code
Date: 2006-05-19 05:54:02
Message-ID: 446D5D7A.3090103@DakotaCom.Net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane wrote:
> Tim Allen <tim(at)proximity(dot)com(dot)au> writes:
>> Don Y wrote:
>>> So, I'll deploy them and get feedback on which features I
>>> may need to add (some of the data types are probably a bit
>>> too exotic for most users). I figure I can always contribute
>>> them just before a release...
>
>> Just before a release would actually be a bad time to contribute the
>> code, if you want to get it accepted into PostgreSQL, as the people who
>> would be competent to review and potentially accept it all tend to be
>> very busy just before a release.
>
> Yeah, I was about to make the same remark. The other thing we see over
> and over is that once some idea or code sees the light of day, there are
> almost always some better ideas offered by someone in the community, and
> thus you need to budget some time for rework in response to comments.
>
> If you're thinking of contributing something major for PG 8.2 (feature
> freeze this July) it's already very late to not have at least a complete
> design out there for public comment.

Note this is losing sight of my original question(s):
Is it possible to have one of my user defined data types
reviewed/critiqued to see if there are things that I am
not doing properly? Or, other things that I should be
including?
In that light, the idea of:
let it run in production for a few months; that will find
far more *realistic* issues than a casual inspection would!
makes perfect sense! I am assuming folks want contributed
code that 1) has been through some significant testing and
2) has been *evaluated* in a real-world environment to find
which features are missing or clumsy. His point (my associate)
is that those of us *needing* these data types are more likely
to find these problems than someone casually reviewing the
code or "playing" with it in a toy environment.

I assumed that the contents of ./contrib have NOT been
thoroughly tested/reviewed by the Postgres team (though
that is just an impression I have... i.e. why have those
features not been INTEGRATED into the codebase?)

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2006-05-19 06:08:01 Re: ALTER SEQUENCE
Previous Message Don Y 2006-05-19 05:42:56 Re: ALTER SEQUENCE