Thread: 8.5 development schedule

Now that 8.4.0 is out the door, development for 8.5devel will be opened any 
day now.  But we haven't discussed the development timeline so far.  The core 
team has several proposals:

CommitFest      Alpha
Aug. 1          Sept. 1
Oct. 1          Nov. 1
Dec. 1          Jan ~~ 5
Feb. 1          March 4

Release ~ May 2010

This puts us on track for a release at the same time next year, maybe a little 
earlier.

("Alpha" is a semiformal snapshot release at the end of the commitfest, for 
those who haven't heard yet.  Details later.)

If we want to avoid a commitfest in December, then this:

CommitFest      Alpha
Sept. 1         Oct. 1
Nov. 1          Dec. 1
Jan. 1          Feb 1
March 1         April 2

Release ~ June 2010

But this has the drawback of waiting an extra month for the first commit fest, 
for no particularly good reason.  (Check the current list, if you are 
curious.)

Or, one more commitfest:

CommitFest      Alpha
Aug. 1          Sept. 1
Oct. 1          Nov. 1
Dec. 1          Jan ~~ 5
Feb. 1          March 3
April 3         May 3

Release ~ July 2010

But that gets 8.5 out even later than this year, and past PGCon.

Comments?

On Tue, Jun 30, 2009 at 1:33 AM, Peter Eisentraut<peter_e@gmx.net> wrote:
> Now that 8.4.0 is out the door, development for 8.5devel will be opened any
> day now.  But we haven't discussed the development timeline so far.  The core
> team has several proposals:
>
> CommitFest      Alpha
> Aug. 1          Sept. 1
> Oct. 1          Nov. 1
> Dec. 1          Jan ~~ 5
> Feb. 1          March 4
>
> Release ~ May 2010
>
> This puts us on track for a release at the same time next year, maybe a little
> earlier.
>
> ("Alpha" is a semiformal snapshot release at the end of the commitfest, for
> those who haven't heard yet.  Details later.)
>
> If we want to avoid a commitfest in December, then this:
>
> CommitFest      Alpha
> Sept. 1         Oct. 1
> Nov. 1          Dec. 1
> Jan. 1          Feb 1
> March 1         April 2
>
> Release ~ June 2010
>
> But this has the drawback of waiting an extra month for the first commit fest,
> for no particularly good reason.  (Check the current list, if you are
> curious.)
>
> Or, one more commitfest:
>
> CommitFest      Alpha
> Aug. 1          Sept. 1
> Oct. 1          Nov. 1
> Dec. 1          Jan ~~ 5
> Feb. 1          March 3
> April 3         May 3
>
> Release ~ July 2010
>
> But that gets 8.5 out even later than this year, and past PGCon.
>
> Comments?

Waiting until September for the first CommitFest seems like a really
bad idea.   We already have almost 40 patches on the wiki page, and
there are some that haven't been added yet: I suspect we will have
over 50 in another week, and maybe closer to 60.  If we wait two
months, we're likely to have 100 patches or more, which will be a
reviewing effort that I don't like to think about.  It will also
increase the number of patches that collide in mid-air.  So at the
very latest, the first CommitFest should start August 1.

However, if anything, I think if anything we should go the other way
and start the first CommitFest July 15th.  That may give people a
little less time than they were expecting to finish up WIP, but I
think it's worth it to give people who have already submitted patches
feedback that much sooner, as well as to maintain reviewer and
committer sanity.

By the way, are going to switch over to the commitfest management tool
I wrote (http://coridan.postgresql.org/)?  There's room for
improvement, but it's a solid starting point, and all the comments I
have received so far have been basically positive.

Also by the way, I'd be willing to be a commitfest manager,
co-commitfest manager, or some other supporting role of that type, if
that would be helpful.

...Robert

On Tue, Jun 30, 2009 at 12:22 PM, Robert Haas<robertmhaas@gmail.com> wrote:
> Waiting until September for the first CommitFest seems like a really
> bad idea.   We already have almost 40 patches on the wiki page, and
> there are some that haven't been added yet: I suspect we will have
> over 50 in another week, and maybe closer to 60.

I would like to propose a different strategy. Instead of always
tackling all the smaller patches and leaving the big patches for last,
I would suggest we start with Hot Standby.

In fact I would suggest as Hot Standby has already gotten a first pass
review that we consider applying it on day 1. That gets it into
everyone's development trees so they can see any suspicious code or
effects it has in their peculiar environments. It may not be perfect
but if we apply it now there's plenty of time to make improvements.

Then we can have a regular commitfest a month or so later. Hopefully
any followon changes to Hot Standby would actually get into that
commitfest if they're relatively minor.

--
greg
http://mit.edu/~gsstark/resume.pdf

On Tue, Jun 30, 2009 at 7:53 AM, Greg Stark<gsstark@mit.edu> wrote:
> On Tue, Jun 30, 2009 at 12:22 PM, Robert Haas<robertmhaas@gmail.com> wrote:
>> Waiting until September for the first CommitFest seems like a really
>> bad idea.   We already have almost 40 patches on the wiki page, and
>> there are some that haven't been added yet: I suspect we will have
>> over 50 in another week, and maybe closer to 60.
>
> I would like to propose a different strategy. Instead of always
> tackling all the smaller patches and leaving the big patches for last,
> I would suggest we start with Hot Standby.
>
> In fact I would suggest as Hot Standby has already gotten a first pass
> review that we consider applying it on day 1. That gets it into
> everyone's development trees so they can see any suspicious code or
> effects it has in their peculiar environments. It may not be perfect
> but if we apply it now there's plenty of time to make improvements.
>
> Then we can have a regular commitfest a month or so later. Hopefully
> any followon changes to Hot Standby would actually get into that
> commitfest if they're relatively minor.

If Hot Standby were ready to be applied, I would be all in favor of
that, but in fact I don't believe that's the case.  There's been no
movement on Hot Standby since February, or at least nothing on the
mailing list and no changes to
http://git.postgresql.org/gitweb?p=simon.git;a=summary

My recollection is there was some discussion of whether Simon was even
prepared to put any more work into that patch or leave it others (in
particular, Heikki) to finish.  I think we had better resolve the
question of who is going to finish that patch and when they plan to do
it before we start planning our CommitFest schedule around it.

...Robert

On Tue, Jun 30, 2009 at 1:04 PM, Robert Haas<robertmhaas@gmail.com> wrote:
> If Hot Standby were ready to be applied, I would be all in favor of
> that, but in fact I don't believe that's the case.  There's been no
> movement on Hot Standby since February

Well Simon was happy with it as submitted so unless people are reading
the patch and giving feedback or using it and running into problems I
wouldn't really expect him to make changes.

That's part of the problem with leaving patches outside the source
tree while they're being developed. It's part of what led us to
suddenly have a massive reviewing job and making big changes in the
final commitfest.

If we apply things earlier in the cycle we can be a lot less
conservative. We don't have to be 100% sure everything was dealt with
in a single commit.

--
greg
http://mit.edu/~gsstark/resume.pdf

On Tue, Jun 30, 2009 at 8:12 AM, Greg Stark<gsstark@mit.edu> wrote:
> On Tue, Jun 30, 2009 at 1:04 PM, Robert Haas<robertmhaas@gmail.com> wrote:
>> If Hot Standby were ready to be applied, I would be all in favor of
>> that, but in fact I don't believe that's the case.  There's been no
>> movement on Hot Standby since February
>
> Well Simon was happy with it as submitted so unless people are reading
> the patch and giving feedback or using it and running into problems I
> wouldn't really expect him to make changes.
>
> That's part of the problem with leaving patches outside the source
> tree while they're being developed. It's part of what led us to
> suddenly have a massive reviewing job and making big changes in the
> final commitfest.
>
> If we apply things earlier in the cycle we can be a lot less
> conservative. We don't have to be 100% sure everything was dealt with
> in a single commit.

+1 (I'm all for getting HS in people's hands ASAP)

Given that there is also a lot of work on synchronous replication, is
it better to get the HS in so the SR stuff can use that as a baseline,
or to triage in both patches together?

merlin

On Tue, Jun 30, 2009 at 8:12 AM, Greg Stark<gsstark@mit.edu> wrote:
> On Tue, Jun 30, 2009 at 1:04 PM, Robert Haas<robertmhaas@gmail.com> wrote:
>> If Hot Standby were ready to be applied, I would be all in favor of
>> that, but in fact I don't believe that's the case.  There's been no
>> movement on Hot Standby since February
>
> Well Simon was happy with it as submitted so unless people are reading
> the patch and giving feedback or using it and running into problems I
> wouldn't really expect him to make changes.

The last substantive email I can find on this topic is:

http://archives.postgresql.org/message-id/1235644369.16176.480.camel@ebony.2ndQuadrant

I would summarize that as saying that Simon was happy with the patch,
but Heikki was not.  Since I think it will be Heikki who ultimately
commits this, the fact that he doesn't feel that it's ready for
prime-time is a pretty important fact that we shouldn't overlook.
Now, it's possible that Heikki has changed his mind, or it's possible
that given where we are in the development cycle he'd be OK comitting
it as-is to 8.5, or it's possible that some work has been done in the
background and there's a committable version now, in which case -
great!  Or, alternatively, if Heikki wants to sit out the next
CommitFest so that he can work on (and hopefully commit) Hot Standby,
also great!  But I don't see why other patches can't be committed in
the meantime, assuming for the moment that they're not things which
are likely to create massive merge problems (then again, the pgindent
run has probably done that already).

In any case, we probably need some weigh-in from Heikki and Simon on
their plans for Hot Standby before we make any decisions...

> That's part of the problem wmith leaving patches outside the source
> tree while they're being developed. It's part of what led us to
> suddenly have a massive reviewing job and making big changes in the
> final commitfest.

Yep. Figuring out what to do about that is a hard problem.

...Robert

Robert Haas <robertmhaas@gmail.com> wrote: 
> Waiting until September for the first CommitFest seems like a really
> bad idea.   We already have almost 40 patches on the wiki page, and
> there are some that haven't been added yet: I suspect we will have
> over 50 in another week, and maybe closer to 60.  If we wait two
> months, we're likely to have 100 patches or more, which will be a
> reviewing effort that I don't like to think about.  It will also
> increase the number of patches that collide in mid-air.  So at the
> very latest, the first CommitFest should start August 1.
> 
> However, if anything, I think if anything we should go the other way
> and start the first CommitFest July 15th.
I'm curious what the counter-arguments to this are.  Is it
review-fatigue from getting the release out, or is there an economy of
scale to building up a 100 patches before starting to review?  Would
reviewing these get some contributors moving again, thus boosting the
total work hours available for the 8.5 release?  Would it pull people
off of WIP?
-Kevin

On Tuesday 30 June 2009 16:50:55 Kevin Grittner wrote:
> > However, if anything, I think if anything we should go the other way
> > and start the first CommitFest July 15th.
>
> I'm curious what the counter-arguments to this are.  Is it
> review-fatigue from getting the release out, or is there an economy of
> scale to building up a 100 patches before starting to review?  Would
> reviewing these get some contributors moving again, thus boosting the
> total work hours available for the 8.5 release?  Would it pull people
> off of WIP?

Well, think about what could happen if we go this way.  What you basically 
have here are people who have essentially ignored the commitfest and beta 
mandates and worked on new patches.  And they now get to say, because we 
already have enough patches, let's start the commit fest early.  And then the 
same people might ignore the commitfest mandate again and produce another 100 
patches by the time this commit fest ends.  So let's start the next commit 
fest right after this one.

So, I think, the schedule should be balanced, reflective of our desired 
development method, independent of momentary circumstances, and certainly not 
unduly influenced by those who chose to ignore the very same schedule.

These points are debatable, but then you are almost debating the point of 
having a schedule at all.

Hi,


>> However, if anything, I think if anything we should go the other way
>> and start the first CommitFest July 15th.
>
> I'm curious what the counter-arguments to this are.  Is it
> review-fatigue from getting the release out, or is there an economy of
> scale to building up a 100 patches before starting to review?  Would
> reviewing these get some contributors moving again, thus boosting the
> total work hours available for the 8.5 release?  Would it pull people
> off of WIP?
>

Agreed, especially for some of the largish WIP (like the partitioning
work for example) patches, a little effort being spent by our
reviewers on agreeing (or disagreeing right now!) on the
direction-implementation being pursued will go a long way in pulling
those efforts off from the WIP mode.

ISTM that identifying and quantifying a certain effort as small,
medium, large and having an appropriate review mechanism in place
might help too.

Regards,
Nikhils
--
http://www.enterprisedb.com

Peter Eisentraut <peter_e@gmx.net> wrote: 
> Well, think about what could happen if we go this way.  What you
> basically have here are people who have essentially ignored the
> commitfest and beta mandates and worked on new patches.  And they
> now get to say, because we already have enough patches, let's start
> the commit fest early.
Well, patches started going onto the wiki page for this commit fest
over seven months ago.  Early review takes on a different meaning in
this context.  I think the basic problem with the schedule at this
point is that we're releasing six months past the planned date; kinda
throws things off.  The question is how to get back on track and avoid
that for 8.5.
You probably have a point in that some of the patches came from people
who might have been able to help more in the review and commit
process, but I think some people lack the confidence to take on that
role; and with the features that dragged out the release half-way to
what would have been our next release date, there probably aren't many
who could have made useful contributions to the review process.
-Kevin

On Tue, Jun 30, 2009 at 10:11 AM, Peter Eisentraut<peter_e@gmx.net> wrote:
> On Tuesday 30 June 2009 16:50:55 Kevin Grittner wrote:
>> > However, if anything, I think if anything we should go the other way
>> > and start the first CommitFest July 15th.
>>
>> I'm curious what the counter-arguments to this are.  Is it
>> review-fatigue from getting the release out, or is there an economy of
>> scale to building up a 100 patches before starting to review?  Would
>> reviewing these get some contributors moving again, thus boosting the
>> total work hours available for the 8.5 release?  Would it pull people
>> off of WIP?
>
> Well, think about what could happen if we go this way.  What you basically
> have here are people who have essentially ignored the commitfest and beta
> mandates and worked on new patches.

Well, the only person who has proposed this so far is me, and I don't
think there can be more than three or four people who are not
committers who put in as much work into the November CommitFest as I
did, and I've already volunteered to do more work for the next
CommitFest.  I'm not exactly sure what the beta mandate is, and I
admit that I haven't done much beta-testing, but even just in the
course of developing the patches I've submitted recently I've found
several bugs which were fixed for 8.4 (try searching your -committers
email for "Robert Haas").  I probably would not have found those bugs
if I had just set out to "test 8.4", because I wouldn't have thought
of those things, so I really feel that I have done as well as I can.
If you disagree, we should discuss, perhaps off-list.

At any rate, the idea that nobody is should do any development during
the seven months for which the tree has been in feature freeze doesn't
seem like a very good one.  If we accept that proposition, then
presumably nobody should also do any development during August,
October, or December, since those months are set aside for
CommitFests.  Therefore, during calendar year 2009, there will be a
total of 91 days during which people are allowed to work on their own
patches, specifically July 1-July 31, September 1-September 30, and
November 1-30.  How are we going to move this project forward by
telling people that they're only allowed to do development 25% of the
days out of the year?  And even if we do accept that proposition, my
proposal to back everything up 15 days wouldn't change the total
number of development days: it would add the second half of December
at the expense of the second half of July.

I'm of the opinion that the way that we should be striving to maximize
the amount of useful development that gets done, and I think the way
to do that is to give people prompt feedback on their patches.  A lot
of the people who have submitted patches for the next CommitFest are
first-time or occasional contributors who may already have lost
interest in the project; waiting longer to review those patches is not
going to increase the chances that those people will eventually get
more involved, either as patch authors or as patch reviewers.  Others
are people like Fujii Masao, Kevin Grittner, and Pavan Deolasee who, I
venture to say, have done enough work on this project to deserve
having their contributions reviewed in a timely fashion, regardless of
exactly when they choose to do their development.  There may be a few
people who aren't carrying the burden of contributing back to the
community, but I don't think it's anything like a majority.

> And they now get to say, because we
> already have enough patches, let's start the commit fest early.  And then the
> same people might ignore the commitfest mandate again and produce another 100
> patches by the time this commit fest ends.  So let's start the next commit
> fest right after this one.

I don't think we have "enough" patches; I'm not sure what that means.
Enough for what?  It would be great if we had more patches, assuming
that they were of good quality and did useful things to advance
PostgreSQL.  What I think we have is a lot of people who are waiting
for feedback, and we should try to give them some.  I also know that
reviewing 60 patches for the November CommitFest was a ton of work,
and the reviewers (including the committers) ran out of steam well
before we got done.  That, and not any desire to jump the queue, is
the reason why I would like to get the reviewing process started
before the patch list grows unmanageably large.

...Robert

Robert Haas <robertmhaas@gmail.com> writes:
> What I think we have is a lot of people who are waiting
> for feedback, and we should try to give them some.  I also know that
> reviewing 60 patches for the November CommitFest was a ton of work,
> and the reviewers (including the committers) ran out of steam well
> before we got done.  That, and not any desire to jump the queue, is
> the reason why I would like to get the reviewing process started
> before the patch list grows unmanageably large.

Yeah.  In core's private discussion of this, I too was arguing for
running a CommitFest ASAP, in order to have some motion on the existing
patch backlog.  I don't know that we'd actually end up committing many,
but we need to provide feedback so people can take the next steps.
People who *were* following the project calendar (like me for instance)
have been largely ignoring the 8.5 queue, so many of those patches are
just sitting out there without any substantive comment.

Right at the moment I imagine a large fraction of those patches are
broken anyway by the recent pgindent run --- has anyone checked?
        regards, tom lane

Greg Stark <gsstark@mit.edu> writes:
> I would like to propose a different strategy. Instead of always
> tackling all the smaller patches and leaving the big patches for last,
> I would suggest we start with Hot Standby.

> In fact I would suggest as Hot Standby has already gotten a first pass
> review that we consider applying it on day 1.

Hot Standby wasn't ready for 8.4, and it's not any more ready now,
because nothing has been done on it since then.  What Simon told us
at the developers' meeting is that he needs to find someone who will
bankroll further work on it.  I hope that will happen, but we can't
design the 8.5 schedule around the assumption that it will.

I'm also not prepared to push a large and unstable feature into the tree
on the hope that it will get fixed.  The general consensus among -core,
and I think most of -hackers as well, is that we want to try to keep CVS
HEAD pretty stable, so that developers aren't fighting each others'
bugs.  This also ties into the "alpha releases" concept that Peter
mentioned --- if HEAD isn't stable then we can hardly put out a testable
alpha release.
        regards, tom lane

Peter Eisentraut <peter_e@gmx.net> writes:
> Now that 8.4.0 is out the door, development for 8.5devel will be opened any 
> day now.  But we haven't discussed the development timeline so far.  The core
> team has several proposals:
> [ details snipped ]

ISTM there are two critical decisions here: when's the first commitfest,
and when's the target release date?  There's already been considerable
chatter about the first decision, but not much about the second.

I would like to propose aiming for a release around April/May 2010 ...
"in time for PGCon" if you like, but the main point is to have it out
before people start disappearing for summer break.  We've already run
into problems with scheduling the 8.4 release because of that.

Or we could slide the target release date into the fall, but it seemed
to me that the spring release timeframe worked better (or would have if
we'd been able to meet it fully).

Of the schedules Peter mentioned, the only one that has a realistic
chance of releasing before June is the one with the final commitfest
starting Feb 1.  Even then, we need to do something to prevent that
fest from expanding the way the last 8.4 fest did.  The core committee
speculated a bit about instituting a rule like "major patches must
be submitted into a CF before the last one; the last one will only
accept resubmissions and small patches".  But then you have to draw
the line between major and minor patches.

Actually, we did have a rule in the 8.4 cycle specifying that we
reserved the right to reject large patches during the final CF.
The problem was that in practice we failed to get up the gumption
to say "no" and make it stick.  This has been a persistent project
management failing for many years, and I'm not sure how we change
that dynamic.  There's always somebody cheerleading for the
latest-and-greatest patch...
        regards, tom lane

On Tue, 2009-06-30 at 12:11 -0400, Tom Lane wrote:

> I'm also not prepared to push a large and unstable feature into the tree
> on the hope that it will get fixed.  The general consensus among -core,
> and I think most of -hackers as well, is that we want to try to keep CVS
> HEAD pretty stable, so that developers aren't fighting each others'
> bugs.  This also ties into the "alpha releases" concept that Peter
> mentioned --- if HEAD isn't stable then we can hardly put out a testable
> alpha release.

+1

Sincerely,

Joshua D. Drake

-- 
PostgreSQL - XMPP: jdrake@jabber.postgresql.org  Consulting, Development, Support, Training  503-667-4564 -
http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
 

On Tue, 2009-06-30 at 12:29 -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Now that 8.4.0 is out the door, development for 8.5devel will be opened any 
> > day now.  But we haven't discussed the development timeline so far.  The core
> > team has several proposals:
> > [ details snipped ]
> 
> ISTM there are two critical decisions here: when's the first commitfest,
> and when's the target release date?  There's already been considerable
> chatter about the first decision, but not much about the second.
> 
> I would like to propose aiming for a release around April/May 2010 ...
> "in time for PGCon" if you like, but the main point is to have it out
> before people start disappearing for summer break.  We've already run
> into problems with scheduling the 8.4 release because of that.

I generally agree with this however why not just have a "When it is
done?". Let's hit some commitfests and some time near the end of the
year start discussing Beta and release.

We are not a company. We don't have a deadline. Why can't we just
develop and say, "Yeah, this looks like it would make a substantive
release."?

Joshua D. Drake

-- 
PostgreSQL - XMPP: jdrake@jabber.postgresql.org  Consulting, Development, Support, Training  503-667-4564 -
http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
 

"Joshua D. Drake" <jd@commandprompt.com> writes:
> On Tue, 2009-06-30 at 12:29 -0400, Tom Lane wrote:
>> I would like to propose aiming for a release around April/May 2010 ...
>> "in time for PGCon" if you like, but the main point is to have it out
>> before people start disappearing for summer break.  We've already run
>> into problems with scheduling the 8.4 release because of that.

> I generally agree with this however why not just have a "When it is
> done?". Let's hit some commitfests and some time near the end of the
> year start discussing Beta and release.

> We are not a company. We don't have a deadline. Why can't we just
> develop and say, "Yeah, this looks like it would make a substantive
> release."?

Well, then you might as well not have a schedule at all.  The point of
setting up a schedule is not to have a deadline that we must meet or
die trying (and certainly not to ship whether it's ready or not, as
a certain other OS database has been accused of doing).  Rather, the
point of this exercise is to give individual developers a framework
to plan in.  Without a target date it's tough to decide what is
reasonable to work on for 8.5.
        regards, tom lane

On Tue, 2009-06-30 at 12:37 -0400, Tom Lane wrote:

> > We are not a company. We don't have a deadline. Why can't we just
> > develop and say, "Yeah, this looks like it would make a substantive
> > release."?
> 
> Well, then you might as well not have a schedule at all.  The point of
> setting up a schedule is not to have a deadline that we must meet or
> die trying (and certainly not to ship whether it's ready or not, as
> a certain other OS database has been accused of doing).  Rather, the
> point of this exercise is to give individual developers a framework
> to plan in.  Without a target date it's tough to decide what is
> reasonable to work on for 8.5.

Right, I get that. That is why I mentioned the start discussing at the
end of the year. The idea being, we really don't know what's going to
hit. So we set a review date of work being done. Say December 1st. On
December 1st we look at what is in, what appears to be coming and "then"
determine a potential release date.

We already push and pull our release dates based are what in the queue,
we just do so informally. Why not just make it part of the process? That
way we are being up front and saying, "Yeah, we have no idea. We will
review in 6 months and that is when we decide our target."

Shrug...

Sincerely,

Joshua D. Drake


> 
>             regards, tom lane
> 
-- 
PostgreSQL - XMPP: jdrake@jabber.postgresql.org  Consulting, Development, Support, Training  503-667-4564 -
http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
 

On Tue, Jun 30, 2009 at 12:37 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>> On Tue, 2009-06-30 at 12:29 -0400, Tom Lane wrote:
>>> I would like to propose aiming for a release around April/May 2010 ...
>>> "in time for PGCon" if you like, but the main point is to have it out
>>> before people start disappearing for summer break.  We've already run
>>> into problems with scheduling the 8.4 release because of that.
>
>> I generally agree with this however why not just have a "When it is
>> done?". Let's hit some commitfests and some time near the end of the
>> year start discussing Beta and release.
>
>> We are not a company. We don't have a deadline. Why can't we just
>> develop and say, "Yeah, this looks like it would make a substantive
>> release."?
>
> Well, then you might as well not have a schedule at all.  The point of
> setting up a schedule is not to have a deadline that we must meet or
> die trying (and certainly not to ship whether it's ready or not, as
> a certain other OS database has been accused of doing).  Rather, the
> point of this exercise is to give individual developers a framework
> to plan in.  Without a target date it's tough to decide what is
> reasonable to work on for 8.5.

I agree.  On the other hand, I think all of the proposed schedules are
somewhat optimistic about how long the final release will take.  We
started the final CommitFest for 8.4 on November 1st and are set to
release July 1st.  The proposed schedule for next time involves
starting the final CommitFest three months later and releasing two
months earlier.  I'd like to think that with a little more discipline
around CommitFests we can tighten things up a little, but it seems
excessively optimistic to think that we're going to cut down from
seven months to two.

I would propose to start CommitFests July 15th, September 15th,
November 15th, and January 15th, planning all but the last to be one
month long.  The last CommitFest I would plan on closing up by March
1st, with release hopefully by June 1st.

As for thresholds, I'd propose that we measure the size of patches
using "diff -u | diffstat".  If the number of insertions plus the
number of deletions is >= 1000, then the patch is not eligible for the
final CommitFest unless it was submitted for the penultimate
CommitFest.  This obvious discriminates against patches with a large
footprint that are not very invasive and in favor of those with a
small footprint that are more destabilizing, but it's a clean line in
the sand, and I think having such a line is better than trying to
apply human judgment to every case.

...Robert

"Joshua D. Drake" <jd@commandprompt.com> writes:
> We already push and pull our release dates based are what in the queue,
> we just do so informally. Why not just make it part of the process? That
> way we are being up front and saying, "Yeah, we have no idea. We will
> review in 6 months and that is when we decide our target."

I think we used to do it more or less like that, but people didn't like
it because they couldn't do any long-range planning.
        regards, tom lane

Robert Haas <robertmhaas@gmail.com> writes:
> I agree.  On the other hand, I think all of the proposed schedules are
> somewhat optimistic about how long the final release will take.  We
> started the final CommitFest for 8.4 on November 1st and are set to
> release July 1st.  The proposed schedule for next time involves
> starting the final CommitFest three months later and releasing two
> months earlier.  I'd like to think that with a little more discipline
> around CommitFests we can tighten things up a little, but it seems
> excessively optimistic to think that we're going to cut down from
> seven months to two.

Yeah.  What I think the 8.4 cycle taught us is that commitfests are a
good thing but they won't magically eliminate the need to say "no" at
the end.  If we are willing to be sufficiently hardnosed about saying
"no", we can make the final commitfest short.  Otherwise it's going to
drag on just like this one did.

Keeping the final-CF-to-release period short is desirable for the
reasons already mentioned --- we don't want to shut down development
for a long period.  So even if it's optimistic, I think we should
write the schedule that way.  We can be certain that the period won't
last *less* time than scheduled :-(

> I would propose to start CommitFests July 15th, September 15th,
> November 15th, and January 15th, planning all but the last to be one
> month long.  The last CommitFest I would plan on closing up by March
> 1st, with release hopefully by June 1st.

Hmm.  If we drop the notion that CFs have to start on month boundaries,
that's actually not a bad schedule --- in particular, it keeps us away
from expecting much of anything to get done in the last half of
December.  I'd suggest setting the target release date to May 15
(pre-PGCon), as long as we're working with ides-of-whichever dates.

> As for thresholds, I'd propose that we measure the size of patches
> using "diff -u | diffstat".  If the number of insertions plus the
> number of deletions is >= 1000, then the patch is not eligible for the
> final CommitFest unless it was submitted for the penultimate
> CommitFest.  This obvious discriminates against patches with a large
> footprint that are not very invasive and in favor of those with a
> small footprint that are more destabilizing, but it's a clean line in
> the sand, and I think having such a line is better than trying to
> apply human judgment to every case.

Well, in the end it will come down to committers' judgements anyway;
if someone thinks a patch is ready it will probably go in, regardless
of size.  But this gives us another tool for saying "no", so I'm
agreeable ;-)
        regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think we used to do it more or less like that, but people
> didn't like it because they couldn't do any long-range planning.
Well, obviously the 8.4 release cycle did little to help them.
As has already been observed, there is a crying need to say "no" at
some point to get a release out.
It might actually help to do that on big patches if we don't let too
many tiny ones accumulate.  I seem to remember the argument being tossed
about that "we might as well keep working on this one because there's
all these others to wrap up."
-Kevin

Robert Haas wrote:
> In any case, we probably need some weigh-in from Heikki and Simon on
> their plans for Hot Standby before we make any decisions...

I'm planning to spend considerable amount of time reviewing and helping
with hot standby and synchronous replication, but someone else will have
to take the lead.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com

Merlin Moncure wrote:
> Given that there is also a lot of work on synchronous replication, is
> it better to get the HS in so the SR stuff can use that as a baseline,
> or to triage in both patches together?

Whichever finishes first. Although they're very useful together, there
is little if any code-level dependency between them. It would be
dangerous to have one wait for the other, as one or the other could well
be delayed for some reason. We can't even be sure that both are finished
in time for 8.5.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com

Kevin Grittner wrote:

> It might actually help to do that on big patches if we don't let too
> many tiny ones accumulate.  I seem to remember the argument being tossed
> about that "we might as well keep working on this one because there's
> all these others to wrap up."

Yeah, and the people who was able to work on the small patches was too
busy helping on the bigger items.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

> I would propose to start CommitFests July 15th, September 15th,
> November 15th, and January 15th, planning all but the last to be one
> month long.  The last CommitFest I would plan on closing up by March
> 1st, with release hopefully by June 1st.

This sounds good to me.  Anyone object?

> As for thresholds, I'd propose that we measure the size of patches
> using "diff -u | diffstat".  If the number of insertions plus the
> number of deletions is>= 1000, then the patch is not eligible for the
> final CommitFest unless it was submitted for the penultimate
> CommitFest.  This obvious discriminates against patches with a large
> footprint that are not very invasive and in favor of those with a
> small footprint that are more destabilizing, but it's a clean line in
> the sand, and I think having such a line is better than trying to
> apply human judgment to every case.

I think we need human judgement.  You could easily make a 4-line change 
to a macro or one of the planner files which would require endless 
debugging.

The deciding people on "big patches" for the final commitfest should be 
a combination of the commitfest managers and the core team.  And we 
should weed out the disqualified before January 15.

-- 
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

On 6/29/09 10:33 PM, Peter Eisentraut wrote:
> Now that 8.4.0 is out the door, development for 8.5devel will be opened any
> day now.  But we haven't discussed the development timeline so far.  The core
> team has several proposals:
>
> CommitFest      Alpha
> Aug. 1          Sept. 1
> Oct. 1          Nov. 1
> Dec. 1          Jan ~~ 5
> Feb. 1          March 4
>
> Release ~ May 2010
>
> This puts us on track for a release at the same time next year, maybe a little
> earlier.

One thing Peter forgot to mention here is that the next-to-last 
commitfest is the *last* commitfest for new major features.  For the 
*last* commitfest, any patch introduced either has to be a resubmission 
of something we've seen at a prior CF, or has to be very "small" (i.e. 
not many lines/files, no side effects, no API or defined standard API).

This makes the next-to-last CF our "biggest" CF.

-- 
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

Josh Berkus <josh@agliodbs.com> writes:
>> I would propose to start CommitFests July 15th, September 15th,
>> November 15th, and January 15th, planning all but the last to be one
>> month long.  The last CommitFest I would plan on closing up by March
>> 1st, with release hopefully by June 1st.

> This sounds good to me.  Anyone object?

I'd like to set the target before PGCon not after; so May 1 or May 15.
Otherwise +1.

> The deciding people on "big patches" for the final commitfest should be 
> a combination of the commitfest managers and the core team.  And we 
> should weed out the disqualified before January 15.

As you say, we should reject outright (at the start of the final CF)
anything that's clearly too big.  But in the final 8.4 CF it didn't
really become clear until later on that some things were not ready or
were too big to deal with.  We need to be more willing to swing the axe
later in the fest, rather than allowing it to drag on "just a bit more"
in the hopes of getting big feature X in.
        regards, tom lane

Josh Berkus <josh@agliodbs.com> writes:
> One thing Peter forgot to mention here is that the next-to-last 
> commitfest is the *last* commitfest for new major features.  For the 
> *last* commitfest, any patch introduced either has to be a resubmission 
> of something we've seen at a prior CF, or has to be very "small" (i.e. 
> not many lines/files, no side effects, no API or defined standard API).

We've been kicking around variations of that idea already.

As I mentioned in the core discussion, I'm a bit concerned that this
would have the effect of choking off development too soon.  We could
have a situation where nothing major is supposed to be getting worked
on from Nov 15 to mid-May, which seems much too long.  So "very small"
seems too strict.  Robert's suggestion of a 1000-line cutoff might be
workable though.
        regards, tom lane

Kevin Grittner wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>  
>> I think we used to do it more or less like that, but people
>> didn't like it because they couldn't do any long-range planning.
>  
> Well, obviously the 8.4 release cycle did little to help them.
>  
> As has already been observed, there is a crying need to say "no" at
> some point to get a release out.
>  
> It might actually help to do that on big patches if we don't let too
> many tiny ones accumulate.  I seem to remember the argument being tossed
> about that "we might as well keep working on this one because there's
> all these others to wrap up."

Have you chaps considered a simple points system? Every patch would need  five minutes attention to triage it into one
of:small (1 point), 
 
medium (2), large (10), huge (50 points - Sync Repl etc). First CF gets 
(say) 200 points, next 150, next 100, next 75. First-come, first-served 
- if your patch goes over the limit it goes in the next commit-fest.

--   Richard Huxton  Archonet Ltd

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > What I think we have is a lot of people who are waiting
> > for feedback, and we should try to give them some.  I also know that
> > reviewing 60 patches for the November CommitFest was a ton of work,
> > and the reviewers (including the committers) ran out of steam well
> > before we got done.  That, and not any desire to jump the queue, is
> > the reason why I would like to get the reviewing process started
> > before the patch list grows unmanageably large.
>
> Yeah.  In core's private discussion of this, I too was arguing for
> running a CommitFest ASAP, in order to have some motion on the existing
> patch backlog.  I don't know that we'd actually end up committing many,
> but we need to provide feedback so people can take the next steps.

I'm in agreement that we should try to provide feedback (in general, to
be honest) on patches/suggestions/ideas/designs/etc as quickly as
possible.  The commitfest approach is good for this when it's "in
motion", but it's been stale for months.  +1 from me for starting early.

To flip it around a bit, I don't know that there's actually a moratorium
on providing feedback?  If people aren't busy working on 8.4 (I hope not
at this point, except testing.. :), have patches that they've submitted
and are waiting for feedback on, or aren't otherwise busy..  I say feel
free to pull patches and review/comment on.  As I like to tell the
people who work with me- being proactive and self-starting is almost
always looked on favorably.

I'm like to encourage the above for the entire development cycle, for
that matter.  Perhaps it won't change much (I'm confident we'll still
need a "commitfest mom", etc) but I don't see why we should actively
prevent it.

> People who *were* following the project calendar (like me for instance)
> have been largely ignoring the 8.5 queue, so many of those patches are
> just sitting out there without any substantive comment.

Certainly following the calendar is a good thing, it's just that we're
about to pass a milestone on the project calendar and need to decide
what we're gonna do next and when.

> Right at the moment I imagine a large fraction of those patches are
> broken anyway by the recent pgindent run --- has anyone checked?

I havn't yet, but it certainly sounds like a great idea.  Maybe we could
even have a "mini-fix-pgindent" commitfest in the last 2 weeks of July..
Thanks,
    Stephen

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> I would like to propose aiming for a release around April/May 2010 ...
> "in time for PGCon" if you like, but the main point is to have it out
> before people start disappearing for summer break.  We've already run
> into problems with scheduling the 8.4 release because of that.

Big +1 from me for having it in time for PGCon.

> Or we could slide the target release date into the fall, but it seemed
> to me that the spring release timeframe worked better (or would have if
> we'd been able to meet it fully).

Agreed.

> Of the schedules Peter mentioned, the only one that has a realistic
> chance of releasing before June is the one with the final commitfest
> starting Feb 1.  Even then, we need to do something to prevent that
> fest from expanding the way the last 8.4 fest did.  The core committee
> speculated a bit about instituting a rule like "major patches must
> be submitted into a CF before the last one; the last one will only
> accept resubmissions and small patches".  But then you have to draw
> the line between major and minor patches.

I liked the general idea of only accepting "already been seen patches"
or "bug-fix only" patches in the last commitfest.
Thanks,
    Stephen

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> As I mentioned in the core discussion, I'm a bit concerned that this
> would have the effect of choking off development too soon.  We could
> have a situation where nothing major is supposed to be getting worked
> on from Nov 15 to mid-May, which seems much too long.  So "very small"
> seems too strict.  Robert's suggestion of a 1000-line cutoff might be
> workable though.

Maybe we should have a hard rule now, but then leave ourselves the
option to relax it (perhaps not publically) once we actually get to the
last CF?  I dunno, just a thought.  I do share your concern about not
choking off development for too long, but it sure seems like we've
always got a big patch or two that we're trying to get into the next
release near the end..
Thanks,
    Stephen

On Tue, Jun 30, 2009 at 9:17 PM, Stephen Frost<sfrost@snowman.net> wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> As I mentioned in the core discussion, I'm a bit concerned that this
>> would have the effect of choking off development too soon.  We could
>> have a situation where nothing major is supposed to be getting worked
>> on from Nov 15 to mid-May, which seems much too long.  So "very small"
>> seems too strict.  Robert's suggestion of a 1000-line cutoff might be
>> workable though.
>
> Maybe we should have a hard rule now, but then leave ourselves the
> option to relax it (perhaps not publically) once we actually get to the
> last CF?  I dunno, just a thought.  I do share your concern about not
> choking off development for too long, but it sure seems like we've
> always got a big patch or two that we're trying to get into the next
> release near the end..

With all due respect, you guys are worrying about the wrong problem.
I suspect it's much more likely that we're going to want to postpone
900-line patches than it is that you're going to want to not postpone
1100-line patches.  If by some chance Tom wants to commit an 1100-line
patch submitted three weeks after the start of the last CommitFest,
he'll explain why he wants to do it and in all likelihood the rest of
us will shrug our shoulders and say "OK, do it".  But I seriously
doubt that's gonna happen.  What's a lot more likely is that Tom will
look at a 900-line patch submitted three weeks BEFORE the start of the
last CommitFest and say "this is going to break a lot of stuff, we
should bounce this to 8.6", and everyone will say "no, it's a great
feature, commit the broken code now! now, we say!".

...Robert

Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Yeah.  In core's private discussion of this, I too was arguing for
>> running a CommitFest ASAP, in order to have some motion on the existing
>> patch backlog.  I don't know that we'd actually end up committing many,
>> but we need to provide feedback so people can take the next steps.

> I'm in agreement that we should try to provide feedback (in general, to
> be honest) on patches/suggestions/ideas/designs/etc as quickly as
> possible.  The commitfest approach is good for this when it's "in
> motion", but it's been stale for months.  +1 from me for starting early.

> To flip it around a bit, I don't know that there's actually a moratorium
> on providing feedback?

Well, I wouldn't put it as strongly as "moratorium", but ... the point
of having a release cycle is that at certain times people are supposed
to focus on stabilizing and testing a release, not on working on new
development.  If, at any time in the past six months, I were to have
gone off and reviewed a patch that's clearly 8.5 material, that's
man-hours taken directly away from getting a solid 8.4 release out the
door.  Which means that much longer until 8.4 does get out, which hurts
everybody including the submitter of the premature patch.  So in general
I agree with the viewpoint Peter outlined that working on new
development during beta period is not really playing by the rules, and
that people who expect feedback for new development during beta period
simply don't understand how the project is supposed to work.

If you find yourself with nothing else to do except review a new patch
during beta, then sure, go do it.  But is there *really* nothing you
could be doing to help expedite the beta?

Anyway, as of now that's all moot until next spring.  But it's still
true that people want time to work on their own patches, which is why
we came up with the commitfests.  It's so you can get some time to work
without feeling guilty about not reviewing other people's work instead.
        regards, tom lane

Josh Berkus wrote:
>
> One thing Peter forgot to mention here is that the next-to-last 
> commitfest is the *last* commitfest for new major features.  For the 
> *last* commitfest, any patch introduced either has to be a 
> resubmission of something we've seen at a prior CF, or has to be very 
> "small" (i.e. not many lines/files, no side effects, no API or defined 
> standard API).
>
> This makes the next-to-last CF our "biggest" CF.

I thought we discussed that at pgCon in May and rejected it.

I have very, very serious reservations about it. I think we need to get 
better about proper triage, especially on the final commitfest, rather 
than moving the effective feature freeze back a whole commitfest.

ISTM we're in danger of becoming dominated by procedures. Let's keep it 
light and loose.

cheers

andrew

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > I'm in agreement that we should try to provide feedback (in general, to
> > be honest) on patches/suggestions/ideas/designs/etc as quickly as
> > possible.  The commitfest approach is good for this when it's "in
> > motion", but it's been stale for months.  +1 from me for starting early.
>
> > To flip it around a bit, I don't know that there's actually a moratorium
> > on providing feedback?
>
> Well, I wouldn't put it as strongly as "moratorium", but ... the point
> of having a release cycle is that at certain times people are supposed
> to focus on stabilizing and testing a release, not on working on new
> development.

I certainly agree with this.  I tried to qualify my comment above in the
sentence which followed it, but apparently I didn't do a good job.

- This only applies before feature freeze (eg: right after 8.4 is out)
- No work being done on a current patch (eg: waiting for feedback)
- Have cycles to spare

Our current arrangment is based on a premise that a given person will
have X cycles in a month to work on PG, and that they have >=X amount
of work to do on developing their patch(s) that month.  I feel like
there are a number of patch submitters who have X cycles to work on PG,
and <X work they'll be able to do on their patch in a given month (in
part because at some point they'll submit it and then wait for
feedback).  I see minimial drawback to encouraging those people to
review other patches with any extra cycles they have, even if we're not
actually in a CF-mode at that point.

> If, at any time in the past six months, I were to have
> gone off and reviewed a patch that's clearly 8.5 material, that's
> man-hours taken directly away from getting a solid 8.4 release out the
> door.  Which means that much longer until 8.4 does get out, which hurts
> everybody including the submitter of the premature patch.  So in general
> I agree with the viewpoint Peter outlined that working on new
> development during beta period is not really playing by the rules, and
> that people who expect feedback for new development during beta period
> simply don't understand how the project is supposed to work.

It wasn't my intent to imply this would be done during feature-freeze,
or beta, but rather something to be done during development.  Perhaps I
should have phrased it as "the moratorium on looking at patches can end
when 8.4 is released, and not be fully reinstated until 8.5 beta".

> Anyway, as of now that's all moot until next spring.  But it's still
> true that people want time to work on their own patches, which is why
> we came up with the commitfests.  It's so you can get some time to work
> without feeling guilty about not reviewing other people's work instead.

I definitely think that's good, and to be honest I don't think my
suggestion would apply to core much at all (they've always got >=X work
to do on patches :), but as we saw during the commitfests in 8.4,
there's a number of non-core folks out there volunteering to review.  If
they're willing and able to spend cycles reviewing other patches rather
than twiddling their thumbs waiting for feedback, let's encourage that.
Thanks,
    Stephen

Tom Lane wrote:
> > As for thresholds, I'd propose that we measure the size of patches
> > using "diff -u | diffstat".  If the number of insertions plus the
> > number of deletions is >= 1000, then the patch is not eligible for the
> > final CommitFest unless it was submitted for the penultimate
> > CommitFest.  This obvious discriminates against patches with a large
> > footprint that are not very invasive and in favor of those with a
> > small footprint that are more destabilizing, but it's a clean line in
> > the sand, and I think having such a line is better than trying to
> > apply human judgment to every case.
> 
> Well, in the end it will come down to committers' judgements anyway;
> if someone thinks a patch is ready it will probably go in, regardless
> of size.  But this gives us another tool for saying "no", so I'm
> agreeable ;-)

I realize there is the perception that the large patches that were
eventually rejected held up the release, but for all the patches I can
think of, they were not rejected immediately _because_ we had other
valid patches to work on.  Once all valid patches were applied, we were
quickly able to reject the large unready patches.

So, rejecting the large patches earily would not have significantly
moved the release date earlier.

--  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 Tue, Jun 30, 2009 at 11:18 PM, Bruce Momjian<bruce@momjian.us> wrote:
> Tom Lane wrote:
>> > As for thresholds, I'd propose that we measure the size of patches
>> > using "diff -u | diffstat".  If the number of insertions plus the
>> > number of deletions is >= 1000, then the patch is not eligible for the
>> > final CommitFest unless it was submitted for the penultimate
>> > CommitFest.  This obvious discriminates against patches with a large
>> > footprint that are not very invasive and in favor of those with a
>> > small footprint that are more destabilizing, but it's a clean line in
>> > the sand, and I think having such a line is better than trying to
>> > apply human judgment to every case.
>>
>> Well, in the end it will come down to committers' judgements anyway;
>> if someone thinks a patch is ready it will probably go in, regardless
>> of size.  But this gives us another tool for saying "no", so I'm
>> agreeable ;-)
>
> I realize there is the perception that the large patches that were
> eventually rejected held up the release, but for all the patches I can
> think of, they were not rejected immediately _because_ we had other
> valid patches to work on.  Once all valid patches were applied, we were
> quickly able to reject the large unready patches.
>
> So, rejecting the large patches earily would not have significantly
> moved the release date earlier.

I don't believe it.  :-)

If the large patches had been rejected earlier, the reviewers and
committers who were spending time on them could have started spending
time on other things sooner.

I also believe, although I cannot prove it, that it would have
increased the pressure to get the remaining items dealt with.  When
there are 100 patches, everyone can say "oh, well it doesn't matter
whether I get this taken care of today, because there will still be 99
other patches".  When there are 3 patches, that argument doesn't hold
water.

Another thing I'd like to improve for the next CommitFest is the
communication between reviewers and committers.  In the November
CommitFest, I, and I think others, assumed that the committers were
reading all of the review threads in detail throughout the process and
that they would jump in when things got close to being done, or maybe
when things got marked as Ready for Committer on the Wiki.  That
worked OK, but there were rough patches where things bogged down.  As
much as we may express opinions on the merits of certain patches, I
think all of us non-committers are (certainly I am) loathe to avoid
the perception that we're telling the committers what to do.  But, I
think it would be helpful to have periodic updates on what the
different committers are currently focused on, how long they intend to
be focused on that, and what they intend to focus on next; and I think
it would be helpful for the CF mgmt team to make suggestions as to
what patches we think are the closest to being ready to go or most in
need of committer-level input.

...Robert

Andrew,

> I thought we discussed that at pgCon in May and rejected it.

That's not what we have in my notes:

http://wiki.postgresql.org/wiki/PgCon_2009_Developer_Meeting#CommitFests

Of course, I may have missed some options, a lot of people were talking.

> I have very, very serious reservations about it. I think we need to get
> better about proper triage, especially on the final commitfest, rather
> than moving the effective feature freeze back a whole commitfest.

Thing is, if we're getting 15,000 lines of code we've never seen before 
(collectively) at the final commitfest, there's simply no way we're 
getting a release out within 3 months of that.

> ISTM we're in danger of becoming dominated by procedures. Let's keep it
> light and loose.

Hmmm ... actually, I think Andrew's right that we don't need a specific 
"last commitfest" rule which is special.  Really, any patch which gets 
submitted to any commitfest gets returned if it's not ready to be 
committed immediately after review.  The only way the last CF is special 
is that anything bounced goes to the next version.

We forgot that with the November CF, which is why it dragged on for 3.5 
months and burned a lot of people out.   Let's just stick to that this 
time and we don't need any new rules.

-- 
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

On Wed, Jul 1, 2009 at 1:16 AM, Josh Berkus<josh@agliodbs.com> wrote:
> Hmmm ... actually, I think Andrew's right that we don't need a specific
> "last commitfest" rule which is special.  Really, any patch which gets
> submitted to any commitfest gets returned if it's not ready to be committed
> immediately after review.  The only way the last CF is special is that
> anything bounced goes to the next version.
>
> We forgot that with the November CF, which is why it dragged on for 3.5
> months and burned a lot of people out.   Let's just stick to that this time
> and we don't need any new rules.

Ugh, I disagree.  I agree that we were too generous with letting
people rework patches while the CommitFest was in progress (mostly, we
let people drop off the map for 3 weeks and then come back and say,
oh, here's my revised version).  But you have to allow a certain
amount of reworking as the CommitFest progresses, I think.  Otherwise,
it just takes way too long to get anything done.

Suppose someone submits a patch that has minor issues to the first
CommitFest.  The reviewer points the issues he sees, so the author
fixes the patch up and resubmits to the second CommitFest.  The patch
is now assigned for review again (possibly to a different reviewer),
and one more minor issue is discovered, so the author fixes up the
patch again and resubmits to the third CommitFest.  Upon third review,
it's discovered that one of the comments is poorly written, so the
author fixes it up again and resubmits to the final CommitFest,
whereupon it is committed.  That's about 7 months to get that patch
committed, and it would be twice that if the initial commitfest was to
the SECOND commitfest rather than the first, since the release cycle
would intervene.

What should actually happen is that the whole thing should be handled
by a single reviewer during one CommitFest.  It's much easier to
re-review a patch that you've read through just a few days prior than
it is to review a whole new patch from scratch, so I don't think it's
imposing an undue burden on the reviewers; in fact it should produce a
net REDUCTION in work by concentrating all the work for a particular
patch into a relatively compact period of time.  What WAS a big
problem during the last CommitFest, at least for me, was resubmits
that didn't happen promptly.  I couldn't decide whether I should
continue starting to review new patches, or whether that would lead to
chaos when all the resubmits from the ones I'd previously reviewed
came back around, leaving me with 4 or 5 patches that all needed to be
reviewed at the same time.  So I'm strongly in favor of a very firm
deadline for resubmits: except for very large patches like HS,
resubmits should be required within, say, 96 hours of the time the
review hits the list; otherwise, we bump it.

Basically, if we're too quick to bump patches to the next CommitFest,
there will be only moderate resistance for the first N-1 CommitFests,
but then for the last CommitFest people won't want to be bumped by a
whole major release for what are basically minor issues.  So we'll be
back in a situation where the last CommitFest is the pits.  We have to
find a middle ground where we're bumping things that are truly holding
things up (tying up reviewer resources or unduly lengthening the
CommitFest) but at the same time avoid bumping things so quickly that
we don't really provide a patch authors with a fair shake at getting
something committed in a reasonable period of time.

...Robert

On Tue, 2009-06-30 at 21:04 +0300, Heikki Linnakangas wrote:
> Merlin Moncure wrote:
> > Given that there is also a lot of work on synchronous replication, is
> > it better to get the HS in so the SR stuff can use that as a baseline,
> > or to triage in both patches together?
> 
> Whichever finishes first. Although they're very useful together, there
> is little if any code-level dependency between them. It would be
> dangerous to have one wait for the other, as one or the other could well
> be delayed for some reason. We can't even be sure that both are finished
> in time for 8.5.

Code dependency is not the main worry. Developer and committer time and
attention is our scarcest resource and I expect it to remain so.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support

On Tue, 2009-06-30 at 09:35 -0400, Robert Haas wrote:

> In any case, we probably need some weigh-in from Heikki and Simon on
> their plans for Hot Standby before we make any decisions...

We discussed this at the developer meeting in May.

I gave a clear commitment to getting Hot Standby into Postgres, and a
wish to see it in 8.5.

I'm going to attempt to get Sync Rep into core first, then Hot Standby.
There are not too many people that have good insight in these areas and
I think we need them all working together to successfully commit
anything to Postgres core that we all agree with. I believe its possible
that individuals may produce working solutions on their own, though I
also believe that constructive teamwork can produce better solutions.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support

On Tue, 2009-06-30 at 08:33 +0300, Peter Eisentraut wrote:

> Now that 8.4.0 is out the door, development for 8.5devel will be
> opened any day now.  But we haven't discussed the development timeline
> so far.

This is a wonderful thing. Development opening quickly and the idea of a
discussed and explicit dev schedule are both good news.

The differences between proposed schedules seems fairly small, so I have
no comment on them other than expressing happiness that they exist.
Thanks.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support

On Wed, 2009-07-01 at 02:14 -0400, Robert Haas wrote:

> Basically, if we're too quick to bump patches to the next CommitFest,
> there will be only moderate resistance for the first N-1 CommitFests,
> but then for the last CommitFest people won't want to be bumped by a
> whole major release for what are basically minor issues.

That is an important point. Remember we are talking about non-committers
here.

Each commitfest needs to be about wrangling in the patches that are
exact or nearly there. Nothing is perfect, especially when the
definition of perfection is not controlled by the patch author. How can
anybody know what will or will not be objected to until the patch is
reviewed?

Committers don't submit perfect patches, they apply them piece by piece,
with comments about "I'll get back to that" or "still thinking of best
way to do it.". Look at the way FOREIGN DATA WRAPPERS got in. Half a
feature, piece by piece (I have zero objection to that, just an
example).

Saying that non-committers need to submit perfect patches or we reject
them just ends up with a pile up. Expecting people that haven't passed a
the bar exam to provide a higher standard of code than those that have
passed the test is obviously not going to work.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support

Bruce Momjian <bruce@momjian.us> wrote: 
> I realize there is the perception that the large patches that were
> eventually rejected held up the release, but for all the patches I
> can think of, they were not rejected immediately _because_ we had
> other valid patches to work on.  Once all valid patches were
> applied, we were quickly able to reject the large unready patches.
> 
> So, rejecting the large patches earily would not have significantly
> moved the release date earlier.
Like Robert, I'm extremely skeptical of this claim, for the same
reasons.
However, even the *possibility* that this could be true is pretty
scary.  If we need to effectively shut down new development for seven
months at the end of a release, in addition to the interim commit
fests, we'd better get a handle on why, so that can change.  To what
do you attribute the extended time needed to handle the final CF?
How can that be made better?
-Kevin

> Ugh, I disagree.  I agree that we were too generous with letting
> people rework patches while the CommitFest was in progress (mostly, we
> let people drop off the map for 3 weeks and then come back and say,
> oh, here's my revised version).  But you have to allow a certain
> amount of reworking as the CommitFest progresses, I think.  Otherwise,
> it just takes way too long to get anything done.

Sure.  The key is "a *certain amount* of reworking".  Not failing to 
respond to review for 3 weeks at a time.  Not introducing APIs or syntax 
extensions which have never been discussed on -hackers before.  Not 
extensive performance testing.  Not saying "here's 3 parts out of 5 of 
the patch, I'll have the other two by the 15th". Not sumbitting a patch 
with no written specification or (for user-facing features) documentation.

That is, the *submitter* should at least think the patch is ready to go.  If people are submitting stuff they *know*
isn'tready to commit, it 
 
should be with a "WIP" flag, which to the reviewers says "review this 
last, or not at all if we run out of time".

And, even if the submitter is being responsive, if we've spent 30 days 
being back-and-forth with the patch, it's just not ready.  Dragging that 
out to 60 days doesn't, according to our history, help.
> I also believe, although I cannot prove it, that it would have> increased the pressure to get the remaining items
dealtwith.  When> there are 100 patches, everyone can say "oh, well it doesn't matter> whether I get this taken care of
today,because there will still be 99> other patches".  When there are 3 patches, that argument doesn't hold> water.
 

I agree.  Closing out 11/08 accelerated once we were down to the last 5 
patches.
> If we need to effectively shut down new development for seven> months at the end of a release, in addition to the
interimcommit> fests, we'd better get a handle on why, so that can change.  To what> do you attribute the extended time
neededto handle the final CF?> How can that be made better?
 

Exactly.  What I think we should be moving towards is the idea that 
*any* commitfest could, with another 30 days of housekeeping, become a 
final release.  The only way to release in a timely fashion is to always 
be ready to release -- this is not just my opinion, but the experience 
of the Ubuntu, Parrot, and several other projects.

Let me point out a worrisome trend:

7.2: 10 months
7.3: 9 months
7.4: 12 months
8.0: 13 months
8.1: 11 months
8.2: 13 months
8.3: 14 months
8.4: 16 months

That's a dangerous-looking progression.  What's worse is that the 
increasing time has always been associated with post feature-freeze; 
i.e. the not-fun post-development period.

Until we embrace the idea that patches will get integrated or rejected 
in a timely fashion, and that we *can* make a target release date, we 
won't.

-- 
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

On Wed, Jul 1, 2009 at 10:30 AM, Kevin
Grittner<Kevin.Grittner@wicourts.gov> wrote:
> Bruce Momjian <bruce@momjian.us> wrote:
>> I realize there is the perception that the large patches that were
>> eventually rejected held up the release, but for all the patches I
>> can think of, they were not rejected immediately _because_ we had
>> other valid patches to work on.  Once all valid patches were
>> applied, we were quickly able to reject the large unready patches.
>>
>> So, rejecting the large patches earily would not have significantly
>> moved the release date earlier.
>
> Like Robert, I'm extremely skeptical of this claim, for the same
> reasons.
>
> However, even the *possibility* that this could be true is pretty
> scary.  If we need to effectively shut down new development for seven
> months at the end of a release, in addition to the interim commit
> fests, we'd better get a handle on why, so that can change.  To what
> do you attribute the extended time needed to handle the final CF?
> How can that be made better?

Hear, hear!

Tom wrote upthread:
# If you find yourself with nothing else to do except review a new patch
# during beta, then sure, go do it.  But is there *really* nothing you
# could be doing to help expedite the beta?

My honest answer to this question is that I have no idea. It was
pretty clear to me what I was supposed to be doing during CommitFest
(reviewing patches) but a lot less clear to me what I should be doing
during beta.  I know that there was an open items list, but it was
never really clear to me how I should help with that.   A lot of the
open items were pretty mushy, subjective issues, or that was how they
seemed to me - not so much "How are we going to fix this?" but "Is
this worth fixing?" and "What kind of fix is appropriate?".  IOW, what
they needed before any useful technical work could be done was
consensus.

Of course, both committers and non-committers need consensus to make
changes, but committers need a lot less consensus.  If no one strongly
objects, they just apply.  Non-committers, on the other hand, need the
affirmative support of a committer to actually perform the commit.
It's a lot easier to get to "no one things this is a really bad idea"
than it is to get to "one of these six people thinks this is a good
idea and that person is willing to devote an hour of their day (or
more) to making it happen".

It seems to me that the solution to this problem is pretty simple.
Committers need to say exactly what kind of help they want; they need
to affirmatively tell other people what to do.  If Tom wants someone
to develop a patch for bug XYZ, he should say that he is prepared to
apply such a patch and ask for volunteers.  That helps path authors in
three ways:

1. Prospective patch authors know that Tom thinks this is important
and that it could hold up the release.
2. Prospective patch authors know that this isn't something that Tom
is already working on.
3. Prospective path authors know that they have a good chance of
getting something applied quickly, without waiting 1-7 months for the
next CommitFest.

I think committers are reluctant to do this for fear of being seen as
pushy, or for fear of being seen to use their status as committers as
way to throw their weight around.  In fact, I've heard more than one
committer make statements of the form, well, we don't really have any
more weight to throw around than anyone else.  The problem with this
is that it's blatantly false, and no non-committer who has taken the
time to write a patch is under any contrary illusion.  If a hamster
and an elephant are trying to sit on the same bench, the hamster does
not want the elephant to assert that he is a hamster; he wants the
elephant to announce his choice of seat prior to putting his bottom in
it.

...Robert

Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>> We already push and pull our release dates based are what in the queue,
>> we just do so informally. Why not just make it part of the process?
> 
> I think we used to do it more or less like that, but people didn't like
> it because they couldn't do any long-range planning.

Does the current system help long-range planning?

I could imagine an enterprise plan that says "we'll upgrade to
the current production release in January [after christmas sales]";
or "we'll begin to upgrade the January after [feature-x] is in
production".

But in neither case does it help my long term planning to know if
the current version January release is scheduled to be called 8.4
or 8.5 or 9.1 (which is really all that the current system helps
me predict).

On Wed, Jul 01, 2009 at 11:51:28AM -0400, Robert Haas wrote:
> Tom wrote upthread:
> # If you find yourself with nothing else to do except review a new patch
> # during beta, then sure, go do it.  But is there *really* nothing you
> # could be doing to help expedite the beta?
>
> My honest answer to this question is that I have no idea. It was
> pretty clear to me what I was supposed to be doing during CommitFest
> (reviewing patches) but a lot less clear to me what I should be doing
> during beta.  I know that there was an open items list, but it was
> never really clear to me how I should help with that.

My feelings as well. During beta, there was clearly work for those with
experience in the areas with open items, and probably for committers
generally, but each time I reviewed the open items list I found little I could
do to help. If there's something I should have found, I'd love for someone to
point it out; in the meantime I tested betas and release candidates in
situtations common to my use of PostgreSQL, and found that it worked to my
satisfaction, after which I was left trying to figure out what to do, and
started dabbling in a patch or two that interested me.

> If a hamster
> and an elephant are trying to sit on the same bench, the hamster does
> not want the elephant to assert that he is a hamster; he wants the
> elephant to announce his choice of seat prior to putting his bottom in

Thanks, Robert -- this made me giggle :)

--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com

Ron Mayer <rm_pg@cheapcomplexdevices.com> wrote: 
> I could imagine an enterprise plan that says "we'll upgrade to
> the current production release in January [after christmas sales]";
> or "we'll begin to upgrade the January after [feature-x] is in
> production".
> 
> But in neither case does it help my long term planning to know if
> the current version January release is scheduled to be called 8.4
> or 8.5 or 9.1 (which is really all that the current system helps
> me predict).
It would help with that if you didn't plan on features which had not
been committed, and the release date didn't slip.  It's been a little
embarrassing at times to have told people not to try to mitigate
performance problems on the application side because I've confirmed
that the semijoin / antijoin code already committed to the 8.4 release
solves the problem, and the release was expected around the start of
the year.
Ultimately, I don't know that it makes sense to plan on any
feature until its patch is accepted, so the best you can do is try to
plan on when the accepted patches will become available.  Almost by
definition, if you want a guarantee that the feature will be in some
release, the date of the release becomes unknowable in advance.
-Kevin

Ron Mayer wrote:

> But in neither case does it help my long term planning to know if
> the current version January release is scheduled to be called 8.4
> or 8.5 or 9.1 (which is really all that the current system helps
> me predict).

The numbering is typically decided near the end of the devel cycle; it's
not set in stone from the beginning.  Witness how 8.0 was slated to be
called 7.5 until it was almost ready ...

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Kevin Grittner wrote:
> Bruce Momjian <bruce@momjian.us> wrote: 
>  
> > I realize there is the perception that the large patches that were
> > eventually rejected held up the release, but for all the patches I
> > can think of, they were not rejected immediately _because_ we had
> > other valid patches to work on.  Once all valid patches were
> > applied, we were quickly able to reject the large unready patches.
> > 
> > So, rejecting the large patches earily would not have significantly
> > moved the release date earlier.
>  
> Like Robert, I'm extremely skeptical of this claim, for the same
> reasons.
>  
> However, even the *possibility* that this could be true is pretty
> scary.  If we need to effectively shut down new development for seven
> months at the end of a release, in addition to the interim commit
> fests, we'd better get a handle on why, so that can change.  To what
> do you attribute the extended time needed to handle the final CF?
> How can that be made better?

We had many patches that had been through previous commit-fests with
minor adjustments and we had to finalize them before we could close the
final commit-fest.  To be clear I am talking about patches that were
eventually applied in 8.4, not patches that were rejected for 8.4.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> wrote: 
> Kevin Grittner wrote:
>> To what do you attribute the extended time needed to handle the
>> final CF? How can that be made better?
> 
> We had many patches that had been through previous commit-fests with
> minor adjustments and we had to finalize them before we could close
> the final commit-fest.  To be clear I am talking about patches that
> were eventually applied in 8.4, not patches that were rejected for
> 8.4.
Thanks.  That answers the first question.
I guess it suggests that the second question could be refined to:
What could have been done to finalize these patches in earlier
commit-fests or bump them to 8.5 before they dragged the process of
wrapping the release by half a year?
-Kevin

Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
> Tom Lane wrote:
>> I think we used to do it more or less like that, but people didn't like
>> it because they couldn't do any long-range planning.

> Does the current system help long-range planning?

> I could imagine an enterprise plan that says "we'll upgrade to
> the current production release in January [after christmas sales]";
> or "we'll begin to upgrade the January after [feature-x] is in
> production".

You have forgotten the context.  This discussion is not about end-user
planning, it is about developer planning.  The issue is whether a
developer should work on feature A that he thinks will take about X
months to finish, or feature B that he thinks will take Y months.
For this purpose it is useful to have an idea of how long it will
be until the next feature freeze.  How long after that the release
will actually hit the street is interesting, but not directly relevant
to whether he's got a chance to get the feature in.
        regards, tom lane

Kevin Grittner wrote:
> Ron Mayer <rm_pg@cheapcomplexdevices.com> wrote: 
>  
> > I could imagine an enterprise plan that says "we'll upgrade to
> > the current production release in January [after christmas sales]";
> > or "we'll begin to upgrade the January after [feature-x] is in
> > production".
> > 
> > But in neither case does it help my long term planning to know if
> > the current version January release is scheduled to be called 8.4
> > or 8.5 or 9.1 (which is really all that the current system helps
> > me predict).
>  
> It would help with that if you didn't plan on features which had not
> been committed, and the release date didn't slip.  It's been a little
> embarrassing at times to have told people not to try to mitigate
> performance problems on the application side because I've confirmed
> that the semijoin / antijoin code already committed to the 8.4 release
> solves the problem, and the release was expected around the start of
> the year.

Where did you see 8.4 was scheduled to be released around the start of
the year?  I never never seen that and would have disputed anyone saying
it publicly.

--  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, 2009-07-01 at 13:39 -0400, Bruce Momjian wrote:

> Where did you see 8.4 was scheduled to be released around the start of
> the year?  I never never seen that and would have disputed anyone saying
> it publicly.

As I understood it, 8.4 was supposed to released at the beginning of Q2.
I never heard or read beginning of the year either.

Joshua D. Drake

-- 
PostgreSQL - XMPP: jdrake@jabber.postgresql.org  Consulting, Development, Support, Training  503-667-4564 -
http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
 

Bruce Momjian <bruce@momjian.us> wrote: 
> Where did you see 8.4 was scheduled to be released around the start
of
> the year?  I never never seen that and would have disputed anyone
saying
> it publicly.
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
That showed a January 1 beta release and a March 1 production release.
-Kevin

On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote:
> Bruce Momjian <bruce@momjian.us> wrote: 
> > Where did you see 8.4 was scheduled to be released around the start
> of
> > the year?  I never never seen that and would have disputed anyone
> saying
> > it publicly.
>  
> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
>  
> That showed a January 1 beta release and a March 1 production release.

Right that would be the expectation I had.

Joshua D. Drake

-- 
PostgreSQL - XMPP: jdrake@jabber.postgresql.org  Consulting, Development, Support, Training  503-667-4564 -
http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
 

"Joshua D. Drake" <jd@commandprompt.com> wrote: 
> On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote:
>> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
>>  
>> That showed a January 1 beta release and a March 1 production
>> release.
> 
> Right that would be the expectation I had.
The first of March is still well into the first quarter; but I was
getting confused about beta versus production release schedules when I
said the release was six months late; it was four months late -- to
the day.
-Kevin

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Bruce Momjian <bruce@momjian.us> wrote: 
>> Where did you see 8.4 was scheduled to be released around the start of
>> the year?
> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
> That showed a January 1 beta release and a March 1 production release.

Terminological problem.  Around here, "release" *always* means
production release.  We don't expect end users to be very interested
in pre-production versions.
        regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> wrote: 
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> That showed a January 1 beta release and a March 1 production
>> release.
> 
> Terminological problem.  Around here, "release" *always* means
> production release.  We don't expect end users to be very interested
> in pre-production versions.
Well, I actually phrased it with managers here that 8.4 was scheduled
to go to beta on January 1st, but that the actual release date was
less predictable because the PostgreSQL community worries more about
having a solid release than hitting a release date.  Based on
discussions on the hackers list, I actually had the impression that
there would be a concerted effort to hit the beta date.
But, yeah -- on this thread I got the dates confused a bit.  I'm happy
to see that the slippage was less severe than I had got myself
thinking it was.  A third of a year, rather than half.
-Kevin

Kevin Grittner wrote:
> "Joshua D. Drake" <jd@commandprompt.com> wrote: 
> > On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote:
>  
> >> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
> >>  
> >> That showed a January 1 beta release and a March 1 production
> >> release.
> > 
> > Right that would be the expectation I had.
>  
> The first of March is still well into the first quarter; but I was
> getting confused about beta versus production release schedules when I
> said the release was six months late; it was four months late -- to
> the day.

OK, that is more accurate, but looking at the schedule:
1st November 2008 - final commit fest begins1st January 2009 - beta 11st March 2009 - 8.4.0 release

How could we have possibly completed the last commit-fest and gotten
ready for beta in two months --- that is just not realistic.  I think we
anticipated a 2x longer final commit-fest, two months, but there was no
time scheduled for actual beta preparation.  I think there was some
ideal that we wouldn't need any time to prepare for beta and that we
would have dealt with all bugs by the time the last commit-fest is
complete, but that is illusory.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Kevin Grittner wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote: 
> > "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> >> That showed a January 1 beta release and a March 1 production
> >> release.
> > 
> > Terminological problem.  Around here, "release" *always* means
> > production release.  We don't expect end users to be very interested
> > in pre-production versions.
>  
> Well, I actually phrased it with managers here that 8.4 was scheduled
> to go to beta on January 1st, but that the actual release date was
> less predictable because the PostgreSQL community worries more about
> having a solid release than hitting a release date.  Based on
> discussions on the hackers list, I actually had the impression that
> there would be a concerted effort to hit the beta date.
>  
> But, yeah -- on this thread I got the dates confused a bit.  I'm happy
> to see that the slippage was less severe than I had got myself
> thinking it was.  A third of a year, rather than half.

And I have just posted that a lack of scheduled time for beta
preparation was one reason for the slippage.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> Where did you see 8.4 was scheduled to be released around the start of
> the year?  I never never seen that and would have disputed anyone saying
> it publicly.

I think people carefully avoided the word "scheduled", but the
press FAQ on www.postgresql.org did say to expect it in Q4 08.


http://archives.postgresql.org/pgsql-general/2009-02/msg01265.php
http://www.postgresql.org/about/press/faq  Q: When will 8.4 come out?  A: Historically, PostgreSQL has released
approximately    every 12 months and there is no desire in the community     to change from that pattern. So expect 8.4
sometimein     the fourth quarter of 2008.
 

Bruce Momjian <bruce@momjian.us> writes:
> OK, that is more accurate, but looking at the schedule:

>     1st November 2008 - final commit fest begins
>     1st January 2009 - beta 1
>     1st March 2009 - 8.4.0 release

> How could we have possibly completed the last commit-fest and gotten
> ready for beta in two months --- that is just not realistic.

We didn't know that at the time, though.  We thought the last CF would
take a month plus.  And up till November the CFs *were* getting done
in about a month.

In retrospect, the CF idea took some of the edge off the problem of
lots of large patches arriving at the feature freeze deadline, but it
is far from having eliminated the problem.
        regards, tom lane

Ron Mayer wrote:
> Bruce Momjian wrote:
> > Where did you see 8.4 was scheduled to be released around the start of
> > the year?  I never never seen that and would have disputed anyone saying
> > it publicly.
> 
> I think people carefully avoided the word "scheduled", but the
> press FAQ on www.postgresql.org did say to expect it in Q4 08.
> 
> 
> http://archives.postgresql.org/pgsql-general/2009-02/msg01265.php
> http://www.postgresql.org/about/press/faq
>    Q: When will 8.4 come out?
>    A: Historically, PostgreSQL has released approximately
>       every 12 months and there is no desire in the community
>       to change from that pattern. So expect 8.4 sometime in
>       the fourth quarter of 2008.

OK, now that someone has brought it up --- I have been disappointed with
the anticipated release dates we broadcast to the press --- without
community approval or oversight.  This is not the first time, but
hopefully it is the last.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> wrote: 
> How could we have possibly completed the last commit-fest and gotten
> ready for beta in two months --- that is just not realistic.  I
> think we anticipated a 2x longer final commit-fest, two months, but
> there was no time scheduled for actual beta preparation.
For my edification, could you point me at something which identifies
the work needed after everything is committed and before the first
beta is released?  (I can't remember reading anything like that, but
it may have fallen through the cracks.)
If no such page exists, could you sketch out a brief outline?
> I think there was some ideal that we wouldn't need any time to
> prepare for beta and that we would have dealt with all bugs by the
> time the last commit-fest is complete, but that is illusory.
I thought one of the purposes of the two-month beta testing phase on
the calendar was to find and fix bugs.  That was in addition to the
two month final commit-fest.
-Kevin

Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
> Bruce Momjian wrote:
>> Where did you see 8.4 was scheduled to be released around the start of
>> the year?  I never never seen that and would have disputed anyone saying
>> it publicly.

> I think people carefully avoided the word "scheduled", but the
> press FAQ on www.postgresql.org did say to expect it in Q4 08.

> http://archives.postgresql.org/pgsql-general/2009-02/msg01265.php
> http://www.postgresql.org/about/press/faq
>    Q: When will 8.4 come out?
>    A: Historically, PostgreSQL has released approximately
>       every 12 months and there is no desire in the community
>       to change from that pattern. So expect 8.4 sometime in
>       the fourth quarter of 2008.

Whoever wrote that certainly didn't ask any of the core hackers about
the phrasing.
        regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > OK, that is more accurate, but looking at the schedule:
> 
> >     1st November 2008 - final commit fest begins
> >     1st January 2009 - beta 1
> >     1st March 2009 - 8.4.0 release
> 
> > How could we have possibly completed the last commit-fest and gotten
> > ready for beta in two months --- that is just not realistic.
> 
> We didn't know that at the time, though.  We thought the last CF would
> take a month plus.  And up till November the CFs *were* getting done
> in about a month.
> 
> In retrospect, the CF idea took some of the edge off the problem of
> lots of large patches arriving at the feature freeze deadline, but it
> is far from having eliminated the problem.

The beta preparation is dealing with all open issues, which is different
than the focus of the commit-fest.  Ideally we would be addressing those
open/bug issues during normal development, but for the hard problems
seem to linger and then we have to deal with them during beta
preparation, which can take 1-2 months.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> In retrospect, the CF idea took some of the edge off the problem of
>> lots of large patches arriving at the feature freeze deadline, but it
>> is far from having eliminated the problem.

> The beta preparation is dealing with all open issues, which is different
> than the focus of the commit-fest.  Ideally we would be addressing those
> open/bug issues during normal development, but for the hard problems
> seem to linger and then we have to deal with them during beta
> preparation, which can take 1-2 months.

We've never scheduled a "beta preparation" phase like that before,
and I don't recall you complaining about the lack of one in the 8.4
schedule.  Personally I think the slip is entirely due to the final
CF taking five months (we closed it 25-March) where we'd expected
something closer to one month.
        regards, tom lane

Kevin Grittner wrote:
> Bruce Momjian <bruce@momjian.us> wrote: 
>  
> > How could we have possibly completed the last commit-fest and gotten
> > ready for beta in two months --- that is just not realistic.  I
> > think we anticipated a 2x longer final commit-fest, two months, but
> > there was no time scheduled for actual beta preparation.
>  
> For my edification, could you point me at something which identifies
> the work needed after everything is committed and before the first
> beta is released?  (I can't remember reading anything like that, but
> it may have fallen through the cracks.)
>  
> If no such page exists, could you sketch out a brief outline?

I just posted on this, but the answer is that commit-fest is for getting
patches applied --- it does not address open bugs that have to be
addressed before we can go to beta.  Those bugs could be new or could be
related to previously-applied patches.  That process can take 1-2
months.

>  
> > I think there was some ideal that we wouldn't need any time to
> > prepare for beta and that we would have dealt with all bugs by the
> > time the last commit-fest is complete, but that is illusory.
>  
> I thought one of the purposes of the two-month beta testing phase on
> the calendar was to find and fix bugs.  That was in addition to the
> two month final commit-fest.

But usually by the time we finish the last commit-fest, we already have
lots of bugs we know about (usually hard to fix), and it doesn't make
sense to go into beta with known bugs.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Tom Lane wrote:
> >> In retrospect, the CF idea took some of the edge off the problem of
> >> lots of large patches arriving at the feature freeze deadline, but it
> >> is far from having eliminated the problem.
> 
> > The beta preparation is dealing with all open issues, which is different
> > than the focus of the commit-fest.  Ideally we would be addressing those
> > open/bug issues during normal development, but for the hard problems
> > seem to linger and then we have to deal with them during beta
> > preparation, which can take 1-2 months.
> 
> We've never scheduled a "beta preparation" phase like that before,
> and I don't recall you complaining about the lack of one in the 8.4
> schedule.  Personally I think the slip is entirely due to the final
> CF taking five months (we closed it 25-March) where we'd expected
> something closer to one month.

I didn't bring it up because the schedule was kind of a first attempt
and it didn't make sense to try and tune it at that point.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> wrote: 
> The beta preparation is dealing with all open issues, which is
> different than the focus of the commit-fest.  Ideally we would be
> addressing those open/bug issues during normal development, but for
> the hard problems seem to linger and then we have to deal with them
> during beta preparation, which can take 1-2 months.
Is there any way to move some of that work up into the earlier commit
fests?  (I'm afraid I still don't have my head around exactly what
sorts of issues are addressed in this phase.)
By the way, I hope that nobody is taking any of my observations or
questions as criticism or complaint.  It seems pretty obvious that the
process currently involves a fair amount of frustration and pain for
all involved, and I'm trying to brainstorm to help.  Don't think for a
minute that I forget or fail to appreciate the tremendous work you do,
along with that done by everyone else.
-Kevin

Kevin Grittner wrote:
> Bruce Momjian <bruce@momjian.us> wrote: 
> > The beta preparation is dealing with all open issues, which is
> > different than the focus of the commit-fest.  Ideally we would be
> > addressing those open/bug issues during normal development, but for
> > the hard problems seem to linger and then we have to deal with them
> > during beta preparation, which can take 1-2 months.
>  
> Is there any way to move some of that work up into the earlier commit
> fests?  (I'm afraid I still don't have my head around exactly what
> sorts of issues are addressed in this phase.)

Basically when someone reports a bug against CVS HEAD we try to fix it
but if the fix is complex, we usually just leave it for later, hence the
beta preparation time.  I think we assume some ideal fix will occur to
us but once we are near beta, we have no more time so we fix it as best
we can.

> By the way, I hope that nobody is taking any of my observations or
> questions as criticism or complaint.  It seems pretty obvious that the
> process currently involves a fair amount of frustration and pain for
> all involved, and I'm trying to brainstorm to help.  Don't think for a
> minute that I forget or fail to appreciate the tremendous work you do,
> along with that done by everyone else.

We understand your motivation.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> writes:
> Kevin Grittner wrote:
>> However, even the *possibility* that this could be true is pretty
>> scary.  If we need to effectively shut down new development for seven
>> months at the end of a release, in addition to the interim commit
>> fests, we'd better get a handle on why, so that can change.  To what
>> do you attribute the extended time needed to handle the final CF?
>> How can that be made better?

> We had many patches that had been through previous commit-fests with
> minor adjustments and we had to finalize them before we could close the
> final commit-fest.  To be clear I am talking about patches that were
> eventually applied in 8.4, not patches that were rejected for 8.4.

I think this is simply not in agreement with the facts.  The patches
that caused the greatest amount of delay for 8.4 were the ones that
ultimately got rejected --- notably hot standby, sync rep, and
sepostgres.  Now the fact that everybody knew they would take awhile
provided some "cover" for other patches that weren't quite ready.
If we had bounced those three on Nov. 1 the commit fest would've been
a lot shorter.  Probably some other things that did get in would've
gotten bounced too, but on the whole I think the project would have been
better off.

The long and the short of it is that there is always tremendous pressure
to include patches that are on the edge of being ready, because we all
know that bouncing them to the next release cycle will mean an extra
year before they're available in production.  The dynamic in 8.4 was
exactly the same as it's been in the prior release cycles: we keep
slipping the possible release date and trying to get those patches
ready, and we don't give up until everyone agrees the release is just
hopelessly late.  As long as we keep behaving that way, no amount of
schedule-setting or rule-making is going to change anything.

It comes down to somebody having the willingness to say "no" and the
authority to make it stick.  Robert mentioned upthread that the
committers don't want to be seen as throwing their weight around,
which is quite true, but I have also noticed in the past that saying
"no" does not convince whoever is arguing that "this release will suck
if it doesn't have this feature".  And there's always somebody arguing
that side --- usually several people.
        regards, tom lane

On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:

> It comes down to somebody having the willingness to say "no" and the
> authority to make it stick.  Robert mentioned upthread that the
> committers don't want to be seen as throwing their weight around,

Is that the purpose of core? To make exactly those decisions? 

Sincerely,

Joshua D. Drake

-- 
PostgreSQL - XMPP: jdrake@jabber.postgresql.org  Consulting, Development, Support, Training  503-667-4564 -
http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
 

"Joshua D. Drake" <jd@commandprompt.com> writes:
> On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
>> It comes down to somebody having the willingness to say "no" and the
>> authority to make it stick.  Robert mentioned upthread that the
>> committers don't want to be seen as throwing their weight around,

> Is that the purpose of core? To make exactly those decisions? 

Core has never seen itself as intended to make feature-by-feature
decisions.  People seem to be willing to defer to us on release
schedule-setting, but it's not clear to me that the community has
delegated us more authority than that.
        regards, tom lane

On Wed, 2009-07-01 at 17:13 -0400, Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
> > On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
> >> It comes down to somebody having the willingness to say "no" and the
> >> authority to make it stick.  Robert mentioned upthread that the
> >> committers don't want to be seen as throwing their weight around,
> 
> > Is that the purpose of core? To make exactly those decisions? 
> 
> Core has never seen itself as intended to make feature-by-feature
> decisions.  People seem to be willing to defer to us on release
> schedule-setting, but it's not clear to me that the community has
> delegated us more authority than that.

I would agree that having core decide on specific features is probably a
stretch but having core set a cut date to which *all* patches that don't
make that date? That seems within purview.

Sincerely,

Joshua D. Drake

-- 
PostgreSQL - XMPP: jdrake@jabber.postgresql.org  Consulting, Development, Support, Training  503-667-4564 -
http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
 

Joshua D. Drake wrote:
> On Wed, 2009-07-01 at 17:13 -0400, Tom Lane wrote:
> > "Joshua D. Drake" <jd@commandprompt.com> writes:
> > > On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
> > >> It comes down to somebody having the willingness to say "no" and the
> > >> authority to make it stick.  Robert mentioned upthread that the
> > >> committers don't want to be seen as throwing their weight around,
> > 
> > > Is that the purpose of core? To make exactly those decisions? 
> > 
> > Core has never seen itself as intended to make feature-by-feature
> > decisions.  People seem to be willing to defer to us on release
> > schedule-setting, but it's not clear to me that the community has
> > delegated us more authority than that.
> 
> I would agree that having core decide on specific features is probably a
> stretch but having core set a cut date to which *all* patches that don't
> make that date? That seems within purview.

Define "make that date"?  That is the problem.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>   
>> On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
>>     
>>> It comes down to somebody having the willingness to say "no" and the
>>> authority to make it stick.  Robert mentioned upthread that the
>>> committers don't want to be seen as throwing their weight around,
>>>       
>
>   
>> Is that the purpose of core? To make exactly those decisions? 
>>     
>
> Core has never seen itself as intended to make feature-by-feature
> decisions.  People seem to be willing to defer to us on release
> schedule-setting, but it's not clear to me that the community has
> delegated us more authority than that.
>
>             
>   


You have correctly identified the requirement in the sentence quoted 
above. I for one am quite prepared to support core or some person 
designated by core having such authority. I agree with you that without 
something like that not much will improve.

cheers

andrew

On Wed, Jul 1, 2009 at 5:01 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>> Kevin Grittner wrote:
>>> However, even the *possibility* that this could be true is pretty
>>> scary.  If we need to effectively shut down new development for seven
>>> months at the end of a release, in addition to the interim commit
>>> fests, we'd better get a handle on why, so that can change.  To what
>>> do you attribute the extended time needed to handle the final CF?
>>> How can that be made better?
>
>> We had many patches that had been through previous commit-fests with
>> minor adjustments and we had to finalize them before we could close the
>> final commit-fest.  To be clear I am talking about patches that were
>> eventually applied in 8.4, not patches that were rejected for 8.4.
>
> I think this is simply not in agreement with the facts.  The patches
> that caused the greatest amount of delay for 8.4 were the ones that
> ultimately got rejected --- notably hot standby, sync rep, and
> sepostgres.  Now the fact that everybody knew they would take awhile

This is also how I remember it.

> provided some "cover" for other patches that weren't quite ready.
> If we had bounced those three on Nov. 1 the commit fest would've been
> a lot shorter.  Probably some other things that did get in would've
> gotten bounced too, but on the whole I think the project would have been
> better off.

It wasn't just the big patches that dragged on forever: for example,
updateable views got submitted literally hours before the start of the
CommitFest in a state where it did not even pass regression tests, I
reviewed it, there was a loooong delay before resubmit, then it got
committed, then it got reverted.  If we had ejected that patch from
the queue (for non-resubmission, if nothing else) early on in the
process, it would have freed up at least three people's time (Tom's,
mine, Peter's) to work on other patches that were in better shape and
submitted sooner.

One of the WORST mistakes that we made with the November CommitFest
was to only assign reviewers to the small patches, figuring that the
committers would look at the big ones.  SE-PostgreSQL was not given a
reasonable review for a very long time.  What we need to do this time
is start with the biggest patches and assign the most capable
reviewers (committers, preferably) to those patches and then work down
the list.  This is another example of the uncomfortable dynamic
between committers and everyone else: non-committers don't feel
comfortable assigning committers to review patches, because who are we
to tell the commiters what to do?  But when the committers are the
only ones competent to do that review, the result is a huge vacuum.
We need to put some structure around this that works.

I do agree, however, that rejecting more patches sooner (in
particular, the ones that had been reviewed and found wanting) would
have been the way to go and good for the project.

> The long and the short of it is that there is always tremendous pressure
> to include patches that are on the edge of being ready, because we all
> know that bouncing them to the next release cycle will mean an extra
> year before they're available in production.  The dynamic in 8.4 was
> exactly the same as it's been in the prior release cycles: we keep
> slipping the possible release date and trying to get those patches
> ready, and we don't give up until everyone agrees the release is just
> hopelessly late.  As long as we keep behaving that way, no amount of
> schedule-setting or rule-making is going to change anything.

Yep.

> It comes down to somebody having the willingness to say "no" and the
> authority to make it stick.  Robert mentioned upthread that the
> committers don't want to be seen as throwing their weight around,
> which is quite true, but I have also noticed in the past that saying
> "no" does not convince whoever is arguing that "this release will suck
> if it doesn't have this feature".  And there's always somebody arguing
> that side --- usually several people.

Yep.  But having a review that clearly enumerates the reasons WHY the
patch needs to be rejected is certainly more compelling than a blanket
statement that the patch is big and invasive and therefore must have
bugs, even if we haven't looked at it enough to find them.  The
blanket statement may be quite true, but it doesn't provide feedback
to the patch author and so fails to accomplish one of the main
purposes of the CommitFests, at least IMO.

...Robert

Bruce Momjian <bruce@momjian.us> wrote: 
> Define "make that date"?  That is the problem.
Not committed by that date.  I guess that leaves the issue of picking
a particular time in a particular time zone, but it doesn't otherwise
seem ambiguous.
Picture the New York Subway system.  You're coming down the stairs and
the train is in sight.  You either make it through the doors before
they close, or you don't.  If you don't, you wait for the next train. 
The system would never work if they held up the train for everyone in
sight of the train who hoped to get on to avoid the wait.  Nobody is
throwing their weight around when those doors close; it's just how the
system works.
-Kevin

Kevin Grittner wrote:
> Bruce Momjian <bruce@momjian.us> wrote: 
>  
> > Define "make that date"?  That is the problem.
>  
> Not committed by that date.  I guess that leaves the issue of picking
> a particular time in a particular time zone, but it doesn't otherwise
> seem ambiguous.
>  
> Picture the New York Subway system.  You're coming down the stairs and
> the train is in sight.  You either make it through the doors before
> they close, or you don't.  If you don't, you wait for the next train. 
> The system would never work if they held up the train for everyone in
> sight of the train who hoped to get on to avoid the wait.  Nobody is
> throwing their weight around when those doors close; it's just how the
> system works.

The problem is that the committers control the commit date, but the one
seen as punished for a rejected patch is not the committers but the
submitter.

--  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 Tue, Jun 30, 2009 at 5:11 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:

> I'm also not prepared to push a large and unstable feature into the tree
> on the hope that it will get fixed.

I didn't have the impression it had any known problems, Simon and
others spent a lot of time testing it already. The improvements Heikki
was asking for were simplifications or cleanup type changes and every
time he asked for something Simon had it done within a day or two.

The problem is I think this will *always* be a "large unstable
feature" just because it's large. If we aren't happy having it in the
tree for alpha releases then there's no circumstance we'll ever be
happy having it in a real release. I think it's a *lot* better having
it in the alpha releases when if we find problems we can revert it or
fix the problems than dropping it at the last second before the betas
when it has to be perfect and there's no second chances.

-- 
greg
http://mit.edu/~gsstark/resume.pdf

Bruce Momjian <bruce@momjian.us> wrote:
> The problem is that the committers control the commit date, but the
> one seen as punished for a rejected patch is not the committers but
> the submitter.
Well, it would seem odd for anyone to feel "punished".
If the patch isn't submitted in good form with the issues hashed out
in prior discussion, and the reviewer(s) and committer(s) can't
resolve the issues prior to the cutoff -- well, try to address those
issues for the next release.  Maybe submit with a bit more lead time
next time around.
As is often pointed out here, nothing stops you from using your own
patch if you need to.  We did so here, for example, with the standard
character string literals.  Had that patch never been accepted, we'd
still be patching new releases.  I'm sure that's not always an option,
but I'll bet it often is.
If the submitter is anxious to make a particular release, they should
be motivated to submit early, turn around quickly, and raise a fuss if
the patch seems to be wanting for attention.
One possible solution would be to have trains leaving the station more
often.  I know that the idea of more frequent releases has been
proposed and rejected before, but that option is sort of screaming to
be considered again in all of this.  Are the mentions of alpha
releases a way to edge into this area -- a feature which misses a
major release could be available to the intrepid within a month or
two, should it then be finished and committed, in a semi-formal way?
-Kevin

bruce wrote:
> I realize there is the perception that the large patches that were
> eventually rejected held up the release, but for all the patches I can
> think of, they were not rejected immediately _because_ we had other
> valid patches to work on.  Once all valid patches were applied, we were
> quickly able to reject the large unready patches.
> 
> So, rejecting the large patches early would not have significantly
> moved the release date earlier.

I see no one agrees with my analysis --- no matter;  if I unreservedly
agreed with others, I wouldn't be here.  ;-)

There has been discussion about how to be more hard-nosed about
rejecting patches.  I think it has to start with us being more
hard-nosed about giving patches feedback --- the very idea we had to
create commit-fests reflects that we historically have not done an
organized job of processing patches.

If we review patches as soon as they appear, and give rapid feedback, we
can easily reject patches that take more than a few days for the patch
author to resolve, and there would be little slippage;  the same goes
for dealing with known bugs.  I know it can be done, but I don't promise
it would be pleasant.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Greg Stark wrote:
> On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> 
> > I'm also not prepared to push a large and unstable feature into the tree
> > on the hope that it will get fixed.
> 
> I didn't have the impression it had any known problems, Simon and
> others spent a lot of time testing it already. The improvements Heikki
> was asking for were simplifications or cleanup type changes and every
> time he asked for something Simon had it done within a day or two.
> 
> The problem is I think this will *always* be a "large unstable
> feature" just because it's large. If we aren't happy having it in the
> tree for alpha releases then there's no circumstance we'll ever be
> happy having it in a real release. I think it's a *lot* better having
> it in the alpha releases when if we find problems we can revert it or
> fix the problems than dropping it at the last second before the betas
> when it has to be perfect and there's no second chances.

By that logic we would never have accepted large patches, but we have,
often.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Greg Stark <gsstark@mit.edu> writes:
> On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>> I'm also not prepared to push a large and unstable feature into the tree
>> on the hope that it will get fixed.

> I didn't have the impression it had any known problems, Simon and
> others spent a lot of time testing it already.

If it didn't have known problems it would have been committed in 8.4.
        regards, tom lane

On Wed, Jul 1, 2009 at 6:53 PM, Kevin
Grittner<Kevin.Grittner@wicourts.gov> wrote:
> Bruce Momjian <bruce@momjian.us> wrote:
>
>> The problem is that the committers control the commit date, but the
>> one seen as punished for a rejected patch is not the committers but
>> the submitter.
>
> Well, it would seem odd for anyone to feel "punished".

Depends on who the patch submitter thinks is at fault.  Sometimes,
patches legitimately don't get reviewed as much as would be good.
Other times, the submitter just thinks the committer is nitpicking.  I
think Bruce summarized it pretty well.

Really, when you get right down to it, you can guarantee that all
patches get a certain amount of review, or you can guarantee that the
CommitFest ends by a certain date, but not both, because you can't
force other people to spend more time on PostgreSQL than they have to
spend.  At best, you can get them to spend the time that they do have
on the right sort of things (e.g. reviewing rather than developing new
patches during CommitFest).

Of course, since you want both of those things to happen, it's a balancing act.

...Robert

On Wed, Jul 1, 2009 at 6:55 PM, Bruce Momjian<bruce@momjian.us> wrote:
> bruce wrote:
>> I realize there is the perception that the large patches that were
>> eventually rejected held up the release, but for all the patches I can
>> think of, they were not rejected immediately _because_ we had other
>> valid patches to work on.  Once all valid patches were applied, we were
>> quickly able to reject the large unready patches.
>>
>> So, rejecting the large patches early would not have significantly
>> moved the release date earlier.
>
> I see no one agrees with my analysis --- no matter;  if I unreservedly
> agreed with others, I wouldn't be here.  ;-)
>
> There has been discussion about how to be more hard-nosed about
> rejecting patches.  I think it has to start with us being more
> hard-nosed about giving patches feedback --- the very idea we had to
> create commit-fests reflects that we historically have not done an
> organized job of processing patches.

Agreed.

> If we review patches as soon as they appear, and give rapid feedback, we
> can easily reject patches that take more than a few days for the patch
> author to resolve, and there would be little slippage;  the same goes
> for dealing with known bugs.  I know it can be done, but I don't promise
> it would be pleasant.

Also agreed.  It's never pleasant to have a patch rejected/postponed,
but it's tolerable if you've gotten some feedback and understand the
reasons why.  Of course there is no guarantee that you will agree with
those reasons, but that's life.  Some day you may be the committer and
have your turn to irritate patch submitters.  :-)

...Robert

Bruce Momjian <bruce@momjian.us> writes:
> There has been discussion about how to be more hard-nosed about
> rejecting patches.  I think it has to start with us being more
> hard-nosed about giving patches feedback --- the very idea we had to
> create commit-fests reflects that we historically have not done an
> organized job of processing patches.

> If we review patches as soon as they appear, and give rapid feedback, we
> can easily reject patches that take more than a few days for the patch
> author to resolve, and there would be little slippage;  the same goes
> for dealing with known bugs.  I know it can be done, but I don't promise
> it would be pleasant.

In other words, you propose dropping the idea of commitfests, and
expecting committers to spend *all* their time reviewing?  Tain't
happening.
        regards, tom lane

Robert Haas wrote:
> > If we review patches as soon as they appear, and give rapid feedback, we
> > can easily reject patches that take more than a few days for the patch
> > author to resolve, and there would be little slippage; ?the same goes
> > for dealing with known bugs. ?I know it can be done, but I don't promise
> > it would be pleasant.
> 
> Also agreed.  It's never pleasant to have a patch rejected/postponed,
> but it's tolerable if you've gotten some feedback and understand the
> reasons why.  Of course there is no guarantee that you will agree with
> those reasons, but that's life.  Some day you may be the committer and
> have your turn to irritate patch submitters.  :-)

Our only limitation is our own sense that we have been fair to patch
authors, i.e. there is no external restriction on how we handle things.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > There has been discussion about how to be more hard-nosed about
> > rejecting patches.  I think it has to start with us being more
> > hard-nosed about giving patches feedback --- the very idea we had to
> > create commit-fests reflects that we historically have not done an
> > organized job of processing patches.
> 
> > If we review patches as soon as they appear, and give rapid feedback, we
> > can easily reject patches that take more than a few days for the patch
> > author to resolve, and there would be little slippage;  the same goes
> > for dealing with known bugs.  I know it can be done, but I don't promise
> > it would be pleasant.
> 
> In other words, you propose dropping the idea of commitfests, and
> expecting committers to spend *all* their time reviewing?  Tain't
> happening.

"I don't promise it would be pleasant."

--  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, Jul 1, 2009 at 7:00 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Greg Stark <gsstark@mit.edu> writes:
>> On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>>> I'm also not prepared to push a large and unstable feature into the tree
>>> on the hope that it will get fixed.
>
>> I didn't have the impression it had any known problems, Simon and
>> others spent a lot of time testing it already.
>
> If it didn't have known problems it would have been committed in 8.4.

What I've seen of Heikki's work thus far has led me to believe that
his reasons for rejecting the patch were good ones, but I don't
specifically what they were.  It would be helpful, I think, to
reiterate them or repost links to the relevant messages in the
archives; it would also be great if we could get an estimate of how
close the patch is to being committable.  Does it still need massive
work, or is it getting fairly close, or what?  Are the issues code
cleanliness/maintainability, bugs, missing functionality?

From our conversations at the PGcon development meeting it seems as
though there are a lot of people for whom this is a high-priority
feature.  Perhaps some of them will be willing to help if we give them
enough information to work with.

...Robert

Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>>> If we review patches as soon as they appear, and give rapid feedback, we
>>> can easily reject patches that take more than a few days for the patch
>>> author to resolve, and there would be little slippage;  the same goes
>>> for dealing with known bugs.  I know it can be done, but I don't promise
>>> it would be pleasant.
>> 
>> In other words, you propose dropping the idea of commitfests, and
>> expecting committers to spend *all* their time reviewing?  Tain't
>> happening.

> "I don't promise it would be pleasant."

I'm not sure which part of "no" you didn't understand, but this
committer is not buying into that proposal.
        regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Tom Lane wrote:
> >> Bruce Momjian <bruce@momjian.us> writes:
> >>> If we review patches as soon as they appear, and give rapid feedback, we
> >>> can easily reject patches that take more than a few days for the patch
> >>> author to resolve, and there would be little slippage;  the same goes
> >>> for dealing with known bugs.  I know it can be done, but I don't promise
> >>> it would be pleasant.
> >> 
> >> In other words, you propose dropping the idea of commitfests, and
> >> expecting committers to spend *all* their time reviewing?  Tain't
> >> happening.
> 
> > "I don't promise it would be pleasant."
> 
> I'm not sure which part of "no" you didn't understand, but this
> committer is not buying into that proposal.

Again, I am pointing out it could be done, but it would be unpleasant,
as you mentioned.  We can't move make progress unless we understand the
underlying causes of our delays.  I am not suggesting we adopt it for
reasons you mentioned.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:
> Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
>> Bruce Momjian wrote:
>>> Where did you see 8.4 was scheduled to be released around the start of
>>> the year?  I never never seen that and would have disputed anyone saying
>>> it publicly.
> 
>> I think people carefully avoided the word "scheduled", but the
>> press FAQ on www.postgresql.org did say to expect it in Q4 08.
> 
>> http://archives.postgresql.org/pgsql-general/2009-02/msg01265.php
>> http://www.postgresql.org/about/press/faq
>>    Q: When will 8.4 come out?
>>    A: Historically, PostgreSQL has released approximately
>>       every 12 months and there is no desire in the community
>>       to change from that pattern. So expect 8.4 sometime in
>>       the fourth quarter of 2008.
> 
> Whoever wrote that certainly didn't ask any of the core hackers about
> the phrasing.

Thtat change was done as part of the website changes for the 8.3 release 
which we usually get through Josh(who is usually creating the 
presskits).The relevant commit message would be: 
https://pgweb.postgresql.org/changeset/1888.


Stefan

On Wed, Jul 1, 2009 at 11:42 PM, Andrew Dunstan<andrew@dunslane.net> wrote:
> You have correctly identified the requirement in the sentence quoted above.
> I for one am quite prepared to support core or some person designated by
> core having such authority. I agree with you that without something like
> that not much will improve.

That's the role of a release manager. Perhaps it's time to think about
designating one for each release to endorse this responsability.

-- 
Guillaume

gsstark@mit.edu (Greg Stark) writes:
> I would like to propose a different strategy. Instead of always
> tackling all the smaller patches and leaving the big patches for last,
> I would suggest we start with Hot Standby.
>
> In fact I would suggest as Hot Standby has already gotten a first pass
> review that we consider applying it on day 1. That gets it into
> everyone's development trees so they can see any suspicious code or
> effects it has in their peculiar environments. It may not be perfect
> but if we apply it now there's plenty of time to make improvements.
>
> Then we can have a regular commitfest a month or so later. Hopefully
> any followon changes to Hot Standby would actually get into that
> commitfest if they're relatively minor.

I could see going either way on this, either:

a) Doing an as-early-as-possible CommitFest to knock off easy items
that have been waiting a while, and having the *second* Fest be the
one where we expect all the large, controversial items to get added
(e.g. - stuff like hot standby, SEPostgreSQL), or

b) Focusing on the likely-hard ones (hot standby, SE PostgreSQL)
first, and deferring others to Fest #2.
-- 
select 'cbbrowne' || '@' || 'acm.org';
http://cbbrowne.com/info/linuxdistributions.html
"Everything should be built top-down, except the first time."
-- Alan J. Perlis

Robert Haas wrote:
> What I've seen of Heikki's work thus far has led me to believe that
> his reasons for rejecting the patch were good ones, but I don't
> specifically what they were.  It would be helpful, I think, to
> reiterate them or repost links to the relevant messages in the
> archives; it would also be great if we could get an estimate of how
> close the patch is to being committable.  Does it still need massive
> work, or is it getting fairly close, or what?  Are the issues code
> cleanliness/maintainability, bugs, missing functionality?

This is where we left off:

http://archives.postgresql.org/message-id/49A64D16.8010105@enterprisedb.com

I was in the process of simplifying Simon's last patch, by removing the
concept of "recovery procs", and simplifying the association between
subxids and top xids is communicated to the slave. The above link
contains an experimental patch for that. The simplifications probably
left behind some more crud that can now be removed, or things that were
broken.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Robert Haas wrote:
>> What I've seen of Heikki's work thus far has led me to believe that
>> his reasons for rejecting the patch were good ones, but I don't
>> specifically what they were.  It would be helpful, I think, to
>> reiterate them or repost links to the relevant messages in the
>> archives; it would also be great if we could get an estimate of how
>> close the patch is to being committable.  Does it still need massive
>> work, or is it getting fairly close, or what?  Are the issues code
>> cleanliness/maintainability, bugs, missing functionality?

> This is where we left off:
> http://archives.postgresql.org/message-id/49A64D16.8010105@enterprisedb.com

There were adjacent remarks suggesting that large other parts of the
patch remained to be reviewed, as well.
http://archives.postgresql.org/pgsql-hackers/2009-02/msg01268.php
        regards, tom lane

On Fri, Jul 3, 2009 at 1:16 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> Robert Haas wrote:
>>> What I've seen of Heikki's work thus far has led me to believe that
>>> his reasons for rejecting the patch were good ones, but I don't
>>> specifically what they were.  It would be helpful, I think, to
>>> reiterate them or repost links to the relevant messages in the
>>> archives; it would also be great if we could get an estimate of how
>>> close the patch is to being committable.  Does it still need massive
>>> work, or is it getting fairly close, or what?  Are the issues code
>>> cleanliness/maintainability, bugs, missing functionality?
>
>> This is where we left off:
>> http://archives.postgresql.org/message-id/49A64D16.8010105@enterprisedb.com
>
> There were adjacent remarks suggesting that large other parts of the
> patch remained to be reviewed, as well.
> http://archives.postgresql.org/pgsql-hackers/2009-02/msg01268.php

Thanks to both of you, this is very helpful.  Two other questions:

1. Are there any chunks of this functionality in this patch that seem
like they might be able to be severed and committed separately?

2. Was the latest version of this patch posted to the mailing list,
and if so can you provide a link?

Thanks,

...Robert

Robert Haas wrote:
> On Fri, Jul 3, 2009 at 1:16 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>>> Robert Haas wrote:
>>>> What I've seen of Heikki's work thus far has led me to believe that
>>>> his reasons for rejecting the patch were good ones, but I don't
>>>> specifically what they were.  It would be helpful, I think, to
>>>> reiterate them or repost links to the relevant messages in the
>>>> archives; it would also be great if we could get an estimate of how
>>>> close the patch is to being committable.  Does it still need massive
>>>> work, or is it getting fairly close, or what?  Are the issues code
>>>> cleanliness/maintainability, bugs, missing functionality?
>>> This is where we left off:
>>> http://archives.postgresql.org/message-id/49A64D16.8010105@enterprisedb.com
>> There were adjacent remarks suggesting that large other parts of the
>> patch remained to be reviewed, as well.
>> http://archives.postgresql.org/pgsql-hackers/2009-02/msg01268.php
> 
> Thanks to both of you, this is very helpful.  Two other questions:
> 
> 1. Are there any chunks of this functionality in this patch that seem
> like they might be able to be severed and committed separately?

I don't think so.

> 2. Was the latest version of this patch posted to the mailing list,
> and if so can you provide a link?

Yes:
http://archives.postgresql.org/message-id/49A64D73.6090302@enterprisedb.com

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com

On Tue, Jun 30, 2009 at 1:33 AM, Peter Eisentraut<peter_e@gmx.net> wrote:
> Now that 8.4.0 is out the door, development for 8.5devel will be opened any
> day now.  But we haven't discussed the development timeline so far.  The core
> team has several proposals:
>
> CommitFest      Alpha
> Aug. 1          Sept. 1
> Oct. 1          Nov. 1
> Dec. 1          Jan ~~ 5
> Feb. 1          March 4
>
> Release ~ May 2010
>
> This puts us on track for a release at the same time next year, maybe a little
> earlier.
>
> ("Alpha" is a semiformal snapshot release at the end of the commitfest, for
> those who haven't heard yet.  Details later.)
>
> If we want to avoid a commitfest in December, then this:
>
> CommitFest      Alpha
> Sept. 1         Oct. 1
> Nov. 1          Dec. 1
> Jan. 1          Feb 1
> March 1         April 2
>
> Release ~ June 2010
>
> But this has the drawback of waiting an extra month for the first commit fest,
> for no particularly good reason.  (Check the current list, if you are
> curious.)
>
> Or, one more commitfest:
>
> CommitFest      Alpha
> Aug. 1          Sept. 1
> Oct. 1          Nov. 1
> Dec. 1          Jan ~~ 5
> Feb. 1          March 3
> April 3         May 3
>
> Release ~ July 2010
>
> But that gets 8.5 out even later than this year, and past PGCon.
>
> Comments?

Now that the first CommitFest is over and done with, it's probably
time to revive this discussion.  If we want people to get big patches
in prior to the last CommitFest, we'd better give the ample warning of
when the penultimate CommitFest is likely to start.

Since we started the first CommitFest on July 15th, and assuming we
want to stick with the timing of one CommitFest every 2 months, a
four-CommitFest cycle would look like this: July 15th, September 15th,
November 15th, January 15th.  A five-CommitFest cycle would add an
additional CommitFest starting March 15th, but I think the last time
we had this discussion, most people were in favor of trying to get 8.5
out the door before PGCon.

I want to point out that if we want to have 8.4 be released at the
same time that 8.5 was, or maybe even a bit earlier in the year so
that it actually is before PGCon, then the right number of CommitFests
is THREE.  Last time, we started the last CommitFest on November 1st.
With a three-CommitFest release, our final CommitFest will begin two
weeks later than it did last year; with a four-CommitFest release, it
will begin a month and a half later.  Even if we assume we'll do a
better job with release management this time, it doesn't seem very
realistic to think that we're going to start the final CommitFest a
month and a half later and get the release out a month sooner.

...Robert

On Mon, 2009-08-17 at 08:04 -0400, Robert Haas wrote:
> Now that the first CommitFest is over and done with,

I think you forgot the part where you tell everyone that it is in fact
done.  I'm waiting on you before I get the alpha release rolling.

On Mon, Aug 17, 2009 at 8:43 AM, Peter Eisentraut<peter_e@gmx.net> wrote:
> On Mon, 2009-08-17 at 08:04 -0400, Robert Haas wrote:
>> Now that the first CommitFest is over and done with,
>
> I think you forgot the part where you tell everyone that it is in fact
> done.  I'm waiting on you before I get the alpha release rolling.

Hmm, it's sort of out of my hands at this point.  There are three
patches left, all of which have been claimed by committers, one of
whom is you.  I don't have any magical powers to control the timing of
committer activity.

But if you're waiting (sorry, didn't realize that), then I think what
we should do is just move those three patches to the next CommitFest.
Then this one will really be done.  I'll go do that now.

...Robert

On mån, 2009-08-17 at 10:22 -0400, Robert Haas wrote:
> On Mon, Aug 17, 2009 at 8:43 AM, Peter Eisentraut<peter_e@gmx.net> wrote:
> > On Mon, 2009-08-17 at 08:04 -0400, Robert Haas wrote:
> >> Now that the first CommitFest is over and done with,
> >
> > I think you forgot the part where you tell everyone that it is in fact
> > done.  I'm waiting on you before I get the alpha release rolling.
> 
> Hmm, it's sort of out of my hands at this point.  There are three
> patches left, all of which have been claimed by committers, one of
> whom is you.  I don't have any magical powers to control the timing of
> committer activity.

Well, in the past the commit fest manager has usually written an email,
"The commit fest is now closed".  Which, as you write, doesn't really
strictly mean anything, just as much as the commit first itself doesn't
really need to mean anything, but appeared to give everyone a sense of
direction and a fuzzy feeling.

Peter Eisentraut <peter_e@gmx.net> wrote: 
> Well, in the past the commit fest manager has usually written an
> email, "The commit fest is now closed".
With the new commitfest software, as the last patch is moved out of
"pending" and the commitfest moved to "closed" status -- I can
practically hear the bang of the gavel.  :-)
-Kevin