Re: 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(at)2ndQuadrant(dot)com www.2ndQuadrant.com

On Tue, Dec 15, 2009 at 12:27 PM, Greg Smith <greg(at)2ndquadrant(dot)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(at)2ndquadrant(dot)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:
> On Tue, Dec 15, 2009 at 12:27 PM, Greg Smith <greg(at)2ndquadrant(dot)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.
>
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
http://archives.postgresql.org/message-id/1260843982.1955.3436.camel@ebony

I just pinged him, and even the first useful step there isn't going to
wrap up in time for this CommitFest and therefore alpha3. Accordingly,
this one is going to stay in "ready for committer" but slip past
stamping the end of this CF. I've marked him as the committer there and
bounced it forward to the next CF.

Simon is still burning the midnight oil to get us a version of HS that
can be committed, the hope is that it's ready to go tomorrow. I think
the best we can do here is to block and/or document any known
limitations/bugs, so long as the feature works for almost all use cases
it seems worth including now. Given that there's a working VF rewrite
patch that just needs final integration and testing, it seems reasonable
to me to commit HS with a warning that VF still has open issues when
combined with that feature. Then everyone can continue to work through
removing any reason you'd need the problematic form of VF anyway, so
that the caveat turns into a non-issue. I'm more concerned about making
sure we get plenty of testing in on HS *alone* to make sure there aren't
any non-HS regressions introduced by its changes, before that gets even
more complicated by adding SR on top of it.

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.

Sounds like we just are waiting for Simon to finish up, which is
expected to happen by tomorrow, and for Tom to wrap up working on the
ProcessUtility_hook. That makes the first reasonable date to consider
alpha3 packaging Thursday 12/17 I think.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com

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(at)2ndquadrant(dot)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:
> Sounds like we just are waiting for Simon to finish up, which is
> expected to happen by tomorrow, and for Tom to wrap up working on the
> ProcessUtility_hook. That makes the first reasonable date to consider
> alpha3 packaging Thursday 12/17 I think.

Update: I just nagged Simon about this some more, as I know everyone is
waiting for this and he's too deep in the code to be real talkative. It
sounds like triage around the issues raised in the "An example of bugs
for Hot Standby" thread is finished at this point, and he's still
hopeful to get this wrapped up and committed this week--which given this
is Friday means real soon now.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com

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(at)2ndQuadrant(dot)com www.2ndQuadrant.com

Thanks Greg - nice job! :-)

On Sat, Dec 19, 2009 at 7:30 AM, Greg Smith <greg(at)2ndquadrant(dot)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(at)2ndQuadrant(dot)com  www.2ndQuadrant.com
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)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(at)pgadmin(dot)org> wrote:

> Thanks Greg - nice job! :-)

+1!

...Robert

So the last commit fest begins 2 days after our meeting. We could still participate though; I'm sure there's plenty of stuff that could be pre-reviewed on the 13th. It's unlikely we'd be able to help by the Feb. meeting.

The other option mentioned was a hack-a-thon. I think it would be best to re-visit that idea later in the year. Only the most trivial of patches would be able to be completed and make it into the commit fest in time.

Another possibility that comes to mind is to see if we can help in some way with beta testing, though obviously that wouldn't be for January.

Begin forwarded message:

> From: Greg Smith <greg(at)2ndquadrant(dot)com>
> Date: December 19, 2009 1:30:43 AM CST
> To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
> Subject: Re: [HACKERS] Closing out CommitFest 2009-11
>
> 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(at)2ndQuadrant(dot)com www.2ndQuadrant.com
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

decibel wrote:
> So the last commit fest begins 2 days after our meeting. We could
> still participate though; I'm sure there's plenty of stuff that could
> be pre-reviewed on the 13th. It's unlikely we'd be able to help by
> the Feb. meeting.
>
> The other option mentioned was a hack-a-thon. I think it would be
> best to re-visit that idea later in the year. Only the most trivial
> of patches would be able to be completed and make it into the commit
> fest in time.
>
> Another possibility that comes to mind is to see if we can help in
> some way with beta testing, though obviously that wouldn't be for
> January.

So, it's about that time...

I'd like to vote for doing a session where we play with / test / discuss
/ explore the new features of the newly released 8.5alpha3!
- --

Jon T Erdman (aka StuckMojo)
PostgreSQL Zealot
-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAktExIIACgkQRAk1+p0GhSFPoACgq8lx/n0mt9FLBr/HDBdKD/nP
DR0AnRqTEYsx5JDpwz0CFcGfZIkVoqIS
=eI2l
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jon Erdman wrote:
> decibel wrote:
>> So the last commit fest begins 2 days after our meeting. We could
>> still participate though; I'm sure there's plenty of stuff that could
>> be pre-reviewed on the 13th. It's unlikely we'd be able to help by
>> the Feb. meeting.
>
>> The other option mentioned was a hack-a-thon. I think it would be
>> best to re-visit that idea later in the year. Only the most trivial
>> of patches would be able to be completed and make it into the commit
>> fest in time.
>
>> Another possibility that comes to mind is to see if we can help in
>> some way with beta testing, though obviously that wouldn't be for
>> January.
>
> So, it's about that time...
>
> I'd like to vote for doing a session where we play with / test / discuss
> / explore the new features of the newly released 8.5alpha3!

Oh, and here's some guidance on doing useful testing:

http://wiki.postgresql.org/wiki/HowToBetaTest
- --

Jon T Erdman (aka StuckMojo)
PostgreSQL Zealot
-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAktExYAACgkQRAk1+p0GhSGKmQCgjGYVLj15tiJIkDzIb+c23SDX
26sAnjoZvXComscqh4boK4r1PDDBLQkF
=T8fV
-----END PGP SIGNATURE-----