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 по дате отправления: