Thread: Please make sure your patches are on the wiki page
Patch submitters, Please make sure your patches are on the November CommitFest wiki page, with correct and updated links. http://wiki.postgresql.org/wiki/CommitFest_2008-11 -- Josh Berkus PostgreSQL San Francisco
I wonder if we should consider: (1) moving all of the patches committed prior to 11/1 to a separate section or page (2) sorting the pending patches by complexity or subject matter ...Robert On Wed, Oct 29, 2008 at 5:26 PM, Josh Berkus <josh@agliodbs.com> wrote: > Patch submitters, > > Please make sure your patches are on the November CommitFest wiki page, with > correct and updated links. > > http://wiki.postgresql.org/wiki/CommitFest_2008-11 > > -- > Josh Berkus > PostgreSQL > San Francisco > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
Robert, > (1) moving all of the patches committed prior to 11/1 to a separate > section or page Why? > (2) sorting the pending patches by complexity or subject matter Sorting them by complexity would be great, if I thought I could do it. I'm not sure I can. -- Josh Berkus PostgreSQL San Francisco
Josh Berkus <josh@agliodbs.com> writes:
>> (2) sorting the pending patches by complexity or subject matter
> Sorting them by complexity would be great, if I thought I could do it. I'm
> not sure I can.
We organized them by subject matter (or code area, really) in a couple
of the earlier fests. I thought that was helpful then. On the other
hand, the September fest didn't seem to break down that way. Until we
see the final list it's hard to say how November will shake out.
Earlier today I had a different thought about how to sort things early
in the fest. I think that there is a strong temptation to finish off
the "simple" patches quickly so as to reduce the size of the list ---
I know I've done that and I think others have too. The trouble with
simple-first is that problematic patches get left till later, which
means that their authors don't have as much time to respond to any
criticisms that may ultimately be forthcoming. I think it'd be a good
idea to intentionally try to focus on difficult patches early, so that
they can be bounced back to their authors with useful criticism while
there's still time to do something in response. Not sure about details
of this, but seems like a process issue that we ought to consider.
regards, tom lane
On Wednesday 29 October 2008 20:12, Tom Lane wrote: > Earlier today I had a different thought about how to sort things early > in the fest. I think that there is a strong temptation to finish off > the "simple" patches quickly so as to reduce the size of the list --- > I know I've done that and I think others have too. Actually, I'd really like it if you and the other advanced hackers ignored the simple patches. I've got a list of 6 new reviewers, and I'd like to be able to give them those patches to review -- they generally can't help with the hard ones. -- Josh Berkus PostgreSQL San Francisco
>> (1) moving all of the patches committed prior to 11/1 to a separate >> section or page > > Why? To reduce clutter, but I don't feel strongly about it. >> (2) sorting the pending patches by complexity or subject matter > > Sorting them by complexity would be great, if I thought I could do it. I'm > not sure I can. I think the biggest patches for this commitfest are SEPostgresql, Simon Riggs' work on hot standby (which is not on the commitfest page yet and probably supersedes some of the earlier patches that are still on there), window functions, DDL lock strength reduction (not sure how big it is but I would guess it probably has to be reviewed by -core), parallel restore, and maybe grouping sets (though it seems like that is a ways from being committable). I agree with Tom that it would probably be good to try to get these (and any other big ones that I may have missed) reviewed by core early and committed or feedback given quickly. It may require some of the other patches to be resnapped to head but that is probably the lesser of two evils. One other random note - I don't believe there has been a new version of the column-level permissions patch that Stephen Frost was working on since the last commitfest. Unless someone disagrees with Markus Wanner's conclusion that it wasn't ready for commit at that point, this one can probably be bounced from the get-go. ...Robert
Robert Haas wrote: > One other random note - I don't believe there has been a new version > of the column-level permissions patch that Stephen Frost was working > on since the last commitfest. Unless someone disagrees with Markus > Wanner's conclusion that it wasn't ready for commit at that point, > this one can probably be bounced from the get-go. FYI, it is going to be though getting SE-Postgres working without column-level permissions. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Wed, 2008-10-29 at 23:12 -0400, Tom Lane wrote: > Earlier today I had a different thought about how to sort things early > in the fest. I think that there is a strong temptation to finish off > the "simple" patches quickly so as to reduce the size of the list --- > I know I've done that and I think others have too. The trouble with > simple-first is that problematic patches get left till later, which > means that their authors don't have as much time to respond to any > criticisms that may ultimately be forthcoming. I think it'd be a good > idea to intentionally try to focus on difficult patches early, so that > they can be bounced back to their authors with useful criticism while > there's still time to do something in response. Not sure about details > of this, but seems like a process issue that we ought to consider. We should probably estimate how many reviews are needed to zero in on the final result. Minor patches are often one hit. Larger patches sometimes need many goes. I think asynch xacts was version 20 something when finally applied. The higher the rating the more important it is to get some early feedback so the authors can keep working. The main thought needs to be: "whats the best way to get the most people actively working on stuff for the release". I might have suggested it before but submitters should also expect to do reviews on other patches. That way everybody understands its a team thing and not fire and forget. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
Bruce Momjian wrote: > Robert Haas wrote: >> One other random note - I don't believe there has been a new version >> of the column-level permissions patch that Stephen Frost was working >> on since the last commitfest. Unless someone disagrees with Markus >> Wanner's conclusion that it wasn't ready for commit at that point, >> this one can probably be bounced from the get-go. > > FYI, it is going to be though getting SE-Postgres working without > column-level permissions. If so, it's too bad. :( Stephen, what is the status of your efforts? The latest one I could found is the "colprivs_wip.20080902.diff.gz". Do you have any updated one? Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
> Stephen, what is the status of your efforts? > The latest one I could found is the "colprivs_wip.20080902.diff.gz". > Do you have any updated one? Snowman told me this week that he was working hard on it -- he declined to be a reviewer for that reason. --Josh
KaiGai, et al,
* KaiGai Kohei (kaigai@kaigai.gr.jp) wrote:
> Stephen, what is the status of your efforts?
I've now got it passing the base regression tests with the actual logic
included in the path. That doesn't mean it works completely, of course,
but I feel like I'm making progress. Feedback, as always, is
appreciated.
> The latest one I could found is the "colprivs_wip.20080902.diff.gz".
> Do you have any updated one?
Please find the latest attached, against current CVS head as of a few
minutes ago (including the change to heap_modify_tuple). I'll also
update the commitfest wiki w/ this once it's hit the archives.
Thanks,
Stephen