Thread: Patch process?

Patch process?

From
Joshua Reich
Date:
Just a general question - I submitted a patch for contrib/cube (adding a 
new function & converting everything from V0 to V1), what is the process 
from here onwards? Do we have an active maintainer of this code? How is 
it reviewed?

I would like to continue working on the cube stuff, as our company uses 
it heavily and has developed a core library of functions that we use 
regularly. I would love to be able to add these back to the Postgres 
project, but I'm not sure about what the guidelines are for contrib. I 
have noticed comments elsewhere about contrib packages being removed 
because they didn't follow guidelines, so I don't want to fall foul of 
that line, but I am not sure where the line is.

I noticed that one of the regression tests now fail, as the original 
regression test expects a certain ordering from a query that doesn't 
request ordered results. Should I fix the test case so that ordering 
will be assured? Should I add test cases for most of the functions that 
currently aren't being tested?

Thanks,

Josh Reich


Re: Patch process?

From
"Marko Kreen"
Date:
On 7/19/06, Joshua Reich <josh@root.net> wrote:
> Just a general question - I submitted a patch for contrib/cube (adding a
> new function & converting everything from V0 to V1), what is the process
> from here onwards? Do we have an active maintainer of this code? How is
> it reviewed?

You should post into -patches@ list, then some core member will
review and apply it.  The review may take some time, you should
not worry about that.  I see that you already got general ACK.

> I would like to continue working on the cube stuff, as our company uses
> it heavily and has developed a core library of functions that we use
> regularly. I would love to be able to add these back to the Postgres
> project, but I'm not sure about what the guidelines are for contrib. I
> have noticed comments elsewhere about contrib packages being removed
> because they didn't follow guidelines, so I don't want to fall foul of
> that line, but I am not sure where the line is.

The line mostly depends on quetions 'Is it useful?' and 'Is it active?'

As you mentioned, it is useful and if you will fix problems then
its also active.  Seeing cvs log of the module, you could consider
becoming the maintainer.

> I noticed that one of the regression tests now fail, as the original
> regression test expects a certain ordering from a query that doesn't
> request ordered results. Should I fix the test case so that ordering
> will be assured? Should I add test cases for most of the functions that
> currently aren't being tested?

Sure, as a maintainer, you should fix all problems :)

-- 
marko


Re: Patch process?

From
Tom Lane
Date:
Joshua Reich <josh@root.net> writes:
> Just a general question - I submitted a patch for contrib/cube (adding a 
> new function & converting everything from V0 to V1), what is the process 
> from here onwards? Do we have an active maintainer of this code?

It sounds like you've just acquired that position ;-)

> How is it reviewed?

Same as everything else, pretty much: patches go to pgsql-patches and
are (supposed to be) reviewed before being committed.  If it's in the
nature of a new feature rather than a simple bug fix or code cleanup,
you might want to first start a discussion on pgsql-hackers --- if
anyone has a better idea about how to do things, it's better to find it
out before you start coding instead of after you finish.

> I noticed that one of the regression tests now fail, as the original 
> regression test expects a certain ordering from a query that doesn't 
> request ordered results. Should I fix the test case so that ordering 
> will be assured? Should I add test cases for most of the functions that 
> currently aren't being tested?

Because we're relying so heavily on the buildfarm these days, failing
regression tests are quite unacceptable.  Adding an ORDER BY might be
the best solution, or maybe you should just change the expected output
--- do you understand exactly why the results changed?  As for adding
more tests, you can within reason --- don't make the running time
enormous.
        regards, tom lane


Re: Patch process?

From
"Dave Page"
Date:

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Marko Kreen
> Sent: 19 July 2006 16:13
> To: Joshua Reich
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Patch process?
>
> On 7/19/06, Joshua Reich <josh@root.net> wrote:
> > Just a general question - I submitted a patch for
> contrib/cube (adding a
> > new function & converting everything from V0 to V1), what
> is the process
> > from here onwards? Do we have an active maintainer of this
> code? How is
> > it reviewed?
>
> You should post into -patches@ list, then some core member will
> review and apply it.

Not core, a committer. Although some people are both, not all are. If
that makes sense!

Regards, Dave.


Re: Patch process?

From
"Marko Kreen"
Date:
On 7/19/06, Dave Page <dpage@vale-housing.co.uk> wrote:
> > You should post into -patches@ list, then some core member will
> > review and apply it.
>
> Not core, a committer. Although some people are both, not all are. If
> that makes sense!

Indeed.

Obviously, non-committers can (and do) review patches.  Just you need
to get the attention of at least one committer to get it into CVS.


-- 
marko


Re: Patch process?

From
Joshua Reich
Date:

Tom Lane wrote:
> Joshua Reich <josh@root.net> writes:
>> Do we have an active maintainer of this code?
> 
> It sounds like you've just acquired that position ;-)

More than happy to take the role.

>> How is it reviewed?
> 
> Same as everything else, pretty much: patches go to pgsql-patches and
> are (supposed to be) reviewed before being committed.  If it's in the
> nature of a new feature rather than a simple bug fix or code cleanup,
> you might want to first start a discussion on pgsql-hackers --- if
> anyone has a better idea about how to do things, it's better to find it
> out before you start coding instead of after you finish.

Ok. I'll keep changes to a minimum; before I add features, I'll discuss 
here.

> Because we're relying so heavily on the buildfarm these days, failing
> regression tests are quite unacceptable.  Adding an ORDER BY might be
> the best solution, or maybe you should just change the expected output
> --- do you understand exactly why the results changed?  As for adding
> more tests, you can within reason --- don't make the running time
> enormous.

Ok. I'll fix the test cases so that everything is hunky dory.

Josh



Re: Patch process?

From
Andrew Dunstan
Date:
Dave Page wrote:

> 
>
>>You should post into -patches@ list, then some core member will
>>review and apply it. 
>>    
>>
>
>Not core, a committer. Although some people are both, not all are. If
>that makes sense!
>
>  
>

I have raised this issue before: I don't believe committers are 
identified as such on the web site, and they (we) probably should be.

cheers

andrew