Thread: Contributing code
Hi, 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? Or, should I just contribute it and hope for the best? (if so, how do I do that?) Thanks! --don
On Tue, May 16, 2006 at 08:12:05PM -0700, Don Y wrote: > Hi, > > 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? Or, should I just contribute it and hope > for the best? (if so, how do I do that?) Put it on a website somewhere and link to. Interested parties could then look at it... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Attachment
Martijn van Oosterhout wrote: > On Tue, May 16, 2006 at 08:12:05PM -0700, Don Y wrote: >> Hi, >> >> 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? Or, should I just contribute it and hope >> for the best? (if so, how do I do that?) > > Put it on a website somewhere and link to. Interested parties could > then look at it... An associate pointed out the obvious: let it run in production for a few months; that will find far more *realistic* issues than a casual inspection would! (Gee, does he distrust my code? :> ). 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... --don
On Wed, May 17, 2006 at 10:46:52AM -0700, Don Y wrote: > Martijn van Oosterhout wrote: > >On Tue, May 16, 2006 at 08:12:05PM -0700, Don Y wrote: > >>Hi, > >> > >>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? Or, should I just contribute it and hope > >>for the best? (if so, how do I do that?) > > > >Put it on a website somewhere and link to. Interested parties could > >then look at it... > > An associate pointed out the obvious: let it run in production > for a few months; that will find far more *realistic* issues > than a casual inspection would! (Gee, does he distrust my > code? :> ). > > 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... Well, in the meantime, if you plan on making it public anyway, why not put it on pgFoundry so that others can poke at it now if the wish? It wouldn't surprise me if right now someone is going "I wish there was something that would let me do..." -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
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. There have been disappointed people in the past for that very reason. The earlier you publish your code, the better. Tim -- ----------------------------------------------- Tim Allen tim@proximity.com.au Proximity Pty Ltd http://www.proximity.com.au/
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.
regards, tom lane
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?)
On Thu, May 18, 2006 at 10:54:02PM -0700, Don Y wrote: > 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?) contrib has been tested to a reasonable level, maybe not as much as the core, but by including it, the core team takes some responsibility for its maintainence. The reasons they're not integrated are varied: - They don't need to be. What they do is not required for standards compliance and most people don't care. However, they're useful to enough people to ship with the main system. - What does "integration" mean anyway. Do we really want fuzzy string matching installed on every postgres system out there by default? In contrib they're easily available for people who want it. We're taking advantage of the fact that postgres is modular, which means we don't need to install heaps of crap into the main system, and instead users can choose which bits they want. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Attachment
On Friday 19 May 2006 01:54, Don Y wrote:
> 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.
>
You're overlooking some critical parts... one being that you can often get
good feedback just by simple code review. The other being that making the
code available also open up the amount of people who can also take said code
and run it in thier "real-world" instances and find issues or make
improvements to it. I recomend posting the code in it's current form and
letting others take a look. It can always be updated later if you find that
there are changes that need to be made... release early, release often eh?
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Fri, May 19, 2006 at 09:37:30AM +0200, Martijn van Oosterhout wrote: > On Thu, May 18, 2006 at 10:54:02PM -0700, Don Y wrote: > > 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?) > > contrib has been tested to a reasonable level, maybe not as much as the > core, but by including it, the core team takes some responsibility for > its maintainence. > > The reasons they're not integrated are varied: > > - They don't need to be. What they do is not required for standards > compliance and most people don't care. However, they're useful to > enough people to ship with the main system. > > - What does "integration" mean anyway. Do we really want fuzzy string > matching installed on every postgres system out there by default? In > contrib they're easily available for people who want it. > > We're taking advantage of the fact that postgres is modular, which > means we don't need to install heaps of crap into the main system, and > instead users can choose which bits they want. Also, some things in contrib are tied into the backend in such a way that they're very version dependant, so it makes sense to keep them in contrib. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461