Обсуждение: Contributing code

Поиск
Список
Период
Сортировка

Contributing code

От
Don Y
Дата:
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

Re: Contributing code

От
Martijn van Oosterhout
Дата:
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.

Вложения

Re: Contributing code

От
Don Y
Дата:
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

Re: Contributing code

От
"Jim C. Nasby"
Дата:
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

Re: Contributing code

От
Tim Allen
Дата:
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/

Re: Contributing code

От
Tom Lane
Дата:
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

Re: Contributing code

От
Don Y
Дата:
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?)

Re: Contributing code

От
Martijn van Oosterhout
Дата:
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.

Вложения

Re: Contributing code

От
Robert Treat
Дата:
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

Re: Contributing code

От
"Jim C. Nasby"
Дата:
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