Re: Contributing code

Поиск
Список
Период
Сортировка
От Don Y
Тема Re: Contributing code
Дата
Msg-id 446D5D7A.3090103@DakotaCom.Net
обсуждение исходный текст
Ответ на Re: Contributing code  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Contributing code  (Martijn van Oosterhout <kleptog@svana.org>)
Re: Contributing code  (Robert Treat <xzilla@users.sourceforge.net>)
Список pgsql-general
Tom Lane wrote:
> Tim Allen <tim@proximity.com.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?)

В списке pgsql-general по дате отправления:

Предыдущее
От: Don Y
Дата:
Сообщение: Re: ALTER SEQUENCE
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ALTER SEQUENCE