Thread: Closing out CommitFest 2009-11
We're down to five patches that are ready for a committer still on the table: -New VACUUM FULL -tsearch parser inefficiency with urls or emails -ProcessUtility_hook -Aggregate ORDER BY support -Hot Standby I just bounced "Streaming Replication" forward to the next CF, and specifically noted the concerns about it linking with libpq. That one seems like it needs more time to brew. Also moved forward all of the still open ECPG patches. With a set of new code just showing up today, I don't think anyone wants to hold up this CF waiting for those to get processed completely. Michael can obviously keep working on them as he gets time. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
On Tue, Dec 15, 2009 at 12:27 PM, Greg Smith <greg@2ndquadrant.com> wrote: > -New VACUUM FULL I get the impression there is still some discussion that needs to happen about the design of this. I think we should mark it Returned with Feedback for now, and let whoever ends up working on it resubmit whatever ends up getting agreed on. > -tsearch parser inefficiency with urls or emails I have been assuming that Teodor would pick this one up, but I don't actually know whether he's planning to look at it. > -ProcessUtility_hook I will take a look at this one (unless Tom beats me to it). > -Aggregate ORDER BY support Tom just committed this one. > -Hot Standby ...and of course Simon has this one. ...Robert
Greg Smith <greg@2ndquadrant.com> writes:
> We're down to five patches that are ready for a committer still on the
> table:
> -New VACUUM FULL
> -tsearch parser inefficiency with urls or emails
> -ProcessUtility_hook
> -Aggregate ORDER BY support
> -Hot Standby
Aggregate ORDER BY is in. I will pick up the ProcessUtility thing next,
since I was the one complaining about the last version of it.
regards, tom lane
Robert Haas wrote: <blockquote cite="mid:603c8f070912151012n60e8b963t69ef79577114d505@mail.gmail.com" type="cite"><pre wrap="">OnTue, Dec 15, 2009 at 12:27 PM, Greg Smith <a class="moz-txt-link-rfc2396E" href="mailto:greg@2ndquadrant.com"><greg@2ndquadrant.com></a>wrote: </pre><blockquote type="cite"><pre wrap="">-NewVACUUM FULL </pre></blockquote><pre wrap=""> I get the impression there is still some discussion that needs to happen about the design of this. I think we should mark it Returned with Feedback for now, and let whoever ends up working on it resubmit whatever ends up getting agreed on. </pre></blockquote> Given that some of the issues here intertwine with Hot Standby integration,Simon has already said he'll work on getting this committed, executing on the plan outlined at <a class="moz-txt-link-freetext" href="http://archives.postgresql.org/message-id/1260843982.1955.3436.camel@ebony">http://archives.postgresql.org/message-id/1260843982.1955.3436.camel@ebony</a><br /><br/> I just pinged him, and even the first useful step there isn't going to wrap up in time for this CommitFest and thereforealpha3. Accordingly, this one is going to stay in "ready for committer" but slip past stamping the end of thisCF. I've marked him as the committer there and bounced it forward to the next CF.<br /><br /> Simon is still burningthe midnight oil to get us a version of HS that can be committed, the hope is that it's ready to go tomorrow. I thinkthe best we can do here is to block and/or document any known limitations/bugs, so long as the feature works for almostall use cases it seems worth including now. Given that there's a working VF rewrite patch that just needs final integrationand testing, it seems reasonable to me to commit HS with a warning that VF still has open issues when combinedwith that feature. Then everyone can continue to work through removing any reason you'd need the problematic formof VF anyway, so that the caveat turns into a non-issue. I'm more concerned about making sure we get plenty of testingin on HS *alone* to make sure there aren't any non-HS regressions introduced by its changes, before that gets evenmore complicated by adding SR on top of it.<br /><br /> As for the tsearch improvements, not to trivialize the patch,but I think this one will survive being committed between alpha3 & CF 2010-01 if it doesn't make it in this week. Teodor can work on getting that committed when he has time, I don't think we need to wait for it.<br /><br /> Soundslike we just are waiting for Simon to finish up, which is expected to happen by tomorrow, and for Tom to wrap up workingon the ProcessUtility_hook. That makes the first reasonable date to consider alpha3 packaging Thursday 12/17 I think.<br/><pre class="moz-signature" cols="72"> -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support <a class="moz-txt-link-abbreviated" href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a> <a class="moz-txt-link-abbreviated"href="http://www.2ndQuadrant.com">www.2ndQuadrant.com</a> </pre>
On Tuesday 15 December 2009 20:44:36 Greg Smith wrote: > As for the tsearch improvements, not to trivialize the patch, but I > think this one will survive being committed between alpha3 & CF 2010-01 > if it doesn't make it in this week. Teodor can work on getting that > committed when he has time, I don't think we need to wait for it. Actually the patch is fairly trivial and fairly unlikely to gain conflicts short of a rewrite of the parser so I don't have any problems with it getting slipped. Andres
Greg Smith <greg@2ndquadrant.com> writes:
> We're down to five patches that are ready for a committer still on the
> table:
> -tsearch parser inefficiency with urls or emails
I just looked at this one and concluded that it was pretty harmless;
will commit it.
regards, tom lane
On Tue, Dec 15, 2009 Greg Smith wrote: <blockquote cite="mid:4B27E724.9000908@2ndquadrant.com" type="cite"> Sounds likewe just are waiting for Simon to finish up, which is expected to happen by tomorrow, and for Tom to wrap up working onthe ProcessUtility_hook. That makes the first reasonable date to consider alpha3 packaging Thursday 12/17 I think.<br/></blockquote><br /> Update: I just nagged Simon about this some more, as I know everyone is waiting for thisand he's too deep in the code to be real talkative. It sounds like triage around the issues raised in the "An exampleof bugs for Hot Standby" thread is finished at this point, and he's still hopeful to get this wrapped up and committedthis week--which given this is Friday means real soon now.<br /><br /><pre class="moz-signature" cols="72">-- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support <a class="moz-txt-link-abbreviated" href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a> <a class="moz-txt-link-abbreviated"href="http://www.2ndQuadrant.com">www.2ndQuadrant.com</a> </pre>
CommitFest 2009-11 is now closed, having committed 27 patches in 33 days. For comparison sake, 2009-09 committed 20 patches in 29 days, 2009-07 37 patches in 34 days, and 2008-09 29 patches in 30 days. The much bigger 2008-11 involved 58 patches going on for months, the bulk of it committed 28 patches in 36 days. Seems pretty consistent at this point: at the average patch contribution size seen over the last year, about one of those gets committed per day once we enter a CommitFest. I didn't bother accounting for things that were committed outside of the official dates, so it's actually a bit worse than that, but that gives a rough idea that's easy to remember. Also, just based on the last three CFs, 42% of patches are either returned with feedback or rejected (with quite a bit more CF to CF variation). The working estimation figure I'd suggest is that once a CF reaches 50 incoming patches it's unlikely that will finish in a month. CommitFest 2010-01, the last one for 8.5, begins on January 15th, 2010. I'll be out of commission with projects by then, so unless Robert wants to reprise his role as CF manager we may need to get someone else involved to do it. Between the CF application and how proactive everyone involved is at this point (almost all authors, reviewers, and committers do the bulk of the state changes and link to messages in the archives for you), the job of running things does keep getting easier. And the guidlines for how to be the CF manager are pretty nailed down now--you could just execute on a pretty mechanical plan and expect to make useful progress. It's still a lot of time though. I've never had an appreciation for exactly how many messages flow through this list like I do now, after a month of needing to read and pay attention to every single one of them. For those of you still furiously working on a patch with that deadline, if you have a large patch and it's not already been reviewed in a previous CommitFest, I wouldn't give you good odds of it being even looked at during that one. There doesn't seem to be any official warning of this where people will likely notice it, but this topic has been discussed on the list here. Large patches submitted just before the deadline for a release have not fared very well historically. Recognizing that, there's really no tolerance for chasing after them (at the expense of postponing the beta) left for this release. Just figured I'd pass along that warning before somebody discovers it the hard way, by working madly to finish their submission up only to see it get kicked to the next version anyway. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
Thanks Greg - nice job! :-) On Sat, Dec 19, 2009 at 7:30 AM, Greg Smith <greg@2ndquadrant.com> wrote: > CommitFest 2009-11 is now closed, having committed 27 patches in 33 days. > For comparison sake, 2009-09 committed 20 patches in 29 days, 2009-07 37 > patches in 34 days, and 2008-09 29 patches in 30 days. The much bigger > 2008-11 involved 58 patches going on for months, the bulk of it committed 28 > patches in 36 days. > > Seems pretty consistent at this point: at the average patch contribution > size seen over the last year, about one of those gets committed per day once > we enter a CommitFest. I didn't bother accounting for things that were > committed outside of the official dates, so it's actually a bit worse than > that, but that gives a rough idea that's easy to remember. > > Also, just based on the last three CFs, 42% of patches are either returned > with feedback or rejected (with quite a bit more CF to CF variation). The > working estimation figure I'd suggest is that once a CF reaches 50 incoming > patches it's unlikely that will finish in a month. > > CommitFest 2010-01, the last one for 8.5, begins on January 15th, 2010. > I'll be out of commission with projects by then, so unless Robert wants to > reprise his role as CF manager we may need to get someone else involved to > do it. Between the CF application and how proactive everyone involved is at > this point (almost all authors, reviewers, and committers do the bulk of the > state changes and link to messages in the archives for you), the job of > running things does keep getting easier. And the guidlines for how to be > the CF manager are pretty nailed down now--you could just execute on a > pretty mechanical plan and expect to make useful progress. It's still a lot > of time though. I've never had an appreciation for exactly how many > messages flow through this list like I do now, after a month of needing to > read and pay attention to every single one of them. > > For those of you still furiously working on a patch with that deadline, if > you have a large patch and it's not already been reviewed in a previous > CommitFest, I wouldn't give you good odds of it being even looked at during > that one. There doesn't seem to be any official warning of this where > people will likely notice it, but this topic has been discussed on the list > here. Large patches submitted just before the deadline for a release have > not fared very well historically. Recognizing that, there's really no > tolerance for chasing after them (at the expense of postponing the beta) > left for this release. Just figured I'd pass along that warning before > somebody discovers it the hard way, by working madly to finish their > submission up only to see it get kicked to the next version anyway. > > -- > Greg Smith 2ndQuadrant Baltimore, MD > PostgreSQL Training, Services and Support > greg@2ndQuadrant.com www.2ndQuadrant.com > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Dec 19, 2009, at 4:07 AM, Dave Page <dpage@pgadmin.org> wrote: > Thanks Greg - nice job! :-) +1! ...Robert