8.5 development schedule

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

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

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.

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