Feature Freeze date for 8.4

On Mon, 22 Oct 2007 19:43:28 +0100
Simon Riggs <simon@2ndquadrant.com> wrote:

For planning purposes, I think its always a good idea to lay down some
dates for the next lot of development milestones. These can be
provisional, until declared solid later.

We can't not realistically consider this until we at least come up with
a release date for 8.3.

I seem to recall that we were originally going to release 8.3 in June.

Jsohua D. Drake

So: When is the next Feature Freeze?

Is it March 31? If not, when?

I know the answer is "too early to tell for certain", but what will it
be if we release in early Dec/early Jan, or whenever.

If we really are very uncertain, lets at least say it will be "Not
Before DateX". PPPPPPP and all that.

AFAICS, more than 50% of the patches are written by professional
developers, so our various sponsors need to know when the next release
is due. Kinda. Ish.

Thank you.

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

On Mon, 2007-10-22 at 11:53 -0700, Joshua D. Drake wrote:

On Mon, 22 Oct 2007 19:43:28 +0100
Simon Riggs <simon@2ndquadrant.com> wrote:

For planning purposes, I think its always a good idea to lay down some
dates for the next lot of development milestones. These can be
provisional, until declared solid later.

We can't not realistically consider this until we at least come up with
a release date for 8.3.

There's always a way of planning through unknowns.

We can issue a provisional date. We could also say "at least 6 months
after release date of 8.3". I'm sure there's other options too.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

Simon,

We can issue a provisional date. We could also say "at least 6 months
after release date of 8.3". I'm sure there's other options too.

I'm going to suggest 4 months after 8.3. 8.3 was supposed to be a *short*
release so that we could move our calendar around. HOT and some of the
other unexpected massive patches prevented that. Again, we have enough in
the "deferred for 8.4" queue that if we finished up only that it would
qualify as a release.

So my thought is, shoot for a short release so that we can get away from
summer consolidations and December releases, and extend the cycle if
someone dumps another 50,000 lines of attractive patches on us.

In fact, I could see doing a "no-catalog-changes, no major patches we don't
already know about, 6-month release". It would reset our cycle and get
PL/proxy, DSM, clustered indexes, etc. out the door. It could mean
turning away patches which look attractive, though, so the whole community
has to be into this.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

Josh Berkus wrote:

In fact, I could see doing a "no-catalog-changes, no major patches we don't
already know about, 6-month release". It would reset our cycle and get
PL/proxy, DSM, clustered indexes, etc. out the door. It could mean
turning away patches which look attractive, though, so the whole community
has to be into this.

Ah, you mean like we planned for 8.0 and failed, then for 8.1 and
failed, then for 8.2 and failed, then for 8.3 and failed? I can
definitely support that idea.

--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
"We are who we choose to be", sang the goldfinch
when the sun is high (Sandman)

Josh Berkus wrote:

So my thought is, shoot for a short release so that we can get away from
summer consolidations and December releases, and extend the cycle if
someone dumps another 50,000 lines of attractive patches on us.

Before we settle on any dates I think we should have some discussion
about how we can shorten the period between feature freeze and beta,
which was far too long this time. Perhaps we need to be more aggressive
about what what makes the cut and what doesn't.

cheers

andrew

On Mon, 22 Oct 2007 16:47:41 -0300
Alvaro Herrera <alvherre@commandprompt.com> wrote:

Josh Berkus wrote:

In fact, I could see doing a "no-catalog-changes, no major patches
we don't already know about, 6-month release". It would reset our
cycle and get PL/proxy, DSM, clustered indexes, etc. out the
door. It could mean turning away patches which look attractive,
though, so the whole community has to be into this.

Ah, you mean like we planned for 8.0 and failed, then for 8.1 and
failed, then for 8.2 and failed, then for 8.3 and failed? I can
definitely support that idea.

As I recall 8.0 and 8.1 actually went pretty well.

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

"Joshua D. Drake" <jd@commandprompt.com> writes:

Alvaro Herrera <alvherre@commandprompt.com> wrote:

Ah, you mean like we planned for 8.0 and failed, then for 8.1 and
failed, then for 8.2 and failed, then for 8.3 and failed? I can
definitely support that idea.

As I recall 8.0 and 8.1 actually went pretty well.

I don't recall any such plans for those releases, but certainly Josh's
proposal is *EXACTLY* what the plan was for 8.3, and look how well we
adhered to that one.

In point of fact, the big patches that aren't in 8.3 were rejected
because they weren't ready. They won't get into 8.4, either, unless
someone does a lot more work on them. So I don't follow this idea
of how we have a pre-loaded queue of good stuff all ready to go into
8.4. We thought that was true for the 8.3 cycle, which it wasn't,
but there isn't even any basis to think that about 8.4.

regards, tom lane

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

In point of fact, the big patches that aren't in 8.3 were rejected
because they weren't ready. They won't get into 8.4, either, unless
someone does a lot more work on them. So I don't follow this idea
of how we have a pre-loaded queue of good stuff all ready to go into
8.4. We thought that was true for the 8.3 cycle, which it wasn't,
but there isn't even any basis to think that about 8.4.

Incidentally what big features do we have in progress?

I see:

. GII - there's been discussion about some kind of refactoring the index api
to avoid the layer violations here.

. Bitmap Indexes - needs a design review and probably changes
possibly needs the same api refactoring as GII

. DSM - I think Heikki's idea to implement the storage via the buffer manager
so it doesn't have fixed size storage limitations like the FSM is a
good one

. Recursive Queries - I haven't really started the meat of it but wouldn't
mind feedback on the outline I posted a while back

There are some more in the developer.postgresql.org patch status page but I'm
not too familiar with what's missing for those.

It does seem like most of these are blocked waiting on ideas rather than SMOP
issues, so I'm not sure counting on them to be ready on a particular schedule
is going to be especially safe. Of course the ideas are more likely to come
once we start discussing the issues. I imagine everyone's focused on the beta
right now.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

josh@agliodbs.com (Josh Berkus) writes:

Simon,

We can issue a provisional date. We could also say "at least 6 months
after release date of 8.3". I'm sure there's other options too.

I'm going to suggest 4 months after 8.3. 8.3 was supposed to be a *short*
release so that we could move our calendar around. HOT and some of the
other unexpected massive patches prevented that. Again, we have enough in
the "deferred for 8.4" queue that if we finished up only that it would
qualify as a release.

So my thought is, shoot for a short release so that we can get away from
summer consolidations and December releases, and extend the cycle if
someone dumps another 50,000 lines of attractive patches on us.

In fact, I could see doing a "no-catalog-changes, no major patches we don't
already know about, 6-month release". It would reset our cycle and get
PL/proxy, DSM, clustered indexes, etc. out the door. It could mean
turning away patches which look attractive, though, so the whole community
has to be into this.

There are good things about that idea.

There would also be good things about picking a somewhat *longer*
cycle in that we already just had a cycle where the "feature freeze"
period was supposedly a short one, which precluded implementing
anything requiring more planning.

- It seems at least somewhat unfair to burden the 8.4 cycle with the
"sins" of the 8.3 cycle.

- There is the risk that even with the restriction, 8.4 might still
not be a short cycle, which would make the attempt futile.

- And would we then say "hey, we need for 8.5 to have a shortened
cycle too"?
--
(reverse (concatenate 'string "ofni.secnanifxunil" "@" "enworbbc"))
http://linuxfinances.info/info/multiplexor.html
Space is big. Really big. You won't believe how vastly
mind-bogglingly big it is. I mean, you may think it's a long way down
the road to the chemist, but that's just peanuts to space. Listen....

Andrew Dunstan <andrew@dunslane.net> writes:

Before we settle on any dates I think we should have some discussion
about how we can shorten the period between feature freeze and beta,
which was far too long this time. Perhaps we need to be more aggressive
about what what makes the cut and what doesn't.

I think basically we need to redefine "feature freeze". The definition
we effectively used for the last couple of cycles was "if you've posted
a patch, even a slushy one, by the stated FF date, you make the cut".
This was compounded in the 8.3 cycle by reviewers (and I'm looking at
myself here) figuring that we could postpone reviewing patches until
after FF because the policy didn't require that they be in good shape
*before* that date. That would've worked OK if there were only a few
such patches, but we had a lot of big ones.

If we want a short FF-to-beta period then the criterion will have to be
that patches are either committed or darn near ready to commit on the FF
date. No springing mostly-done patches on the community a few days
before FF. And the reviewers will need to work harder on reviewing
stuff earlier, and committing before FF whenever possible. And we need
to be much more ready to bounce stuff that's not quite done, rather than
drag out the cycle to let it get finished.

No, it doesn't sound like any fun :-(. But this cycle was clearly
mismanaged. It's not productive to have a freeze this long.

[ thinks for a bit... ] A truly hard-nosed approach would be to define
FF as "if your patch isn't committed by the FF date, you lose". The
FF-to-beta delay then is only long enough to make sure we've documented
everything, written release notes, etc. I'm not sure this would be a
more pleasant way to work, as there'd be a heck of a lot of pressure on
the committers as the days tick down to FF. But it'd fix the scheduling
problem.

regards, tom lane

Chris Browne <cbbrowne@acm.org> writes:

josh@agliodbs.com (Josh Berkus) writes:

In fact, I could see doing a "no-catalog-changes, no major patches we don't
already know about, 6-month release". It would reset our cycle and get
PL/proxy, DSM, clustered indexes, etc. out the door. It could mean
turning away patches which look attractive, though, so the whole community
has to be into this.

There are good things about that idea.

There would also be good things about picking a somewhat *longer*
cycle in that we already just had a cycle where the "feature freeze"
period was supposedly a short one, which precluded implementing
anything requiring more planning.

[ chewing on this a bit... ] The curious thing about that is that
despite this being designed to be a short release cycle, we ended up
landing a bunch of major patches that weren't on the radar screen at
all at the start of the cycle. This suggests to me that there's
something wrong with the concept that no one can get anything major done
without a long release cycle to do it in.

Indeed, the thing that seemed to me to be killing us in this freeze
cycle was that the patches coming in were already at the upper limit of
what we can review and digest. I don't think I want to say "okay guys,
we'll give you a year so that you can write a 200K-line patch and drop
it on us the day before feature freeze".

I'd rather encourage people to work in an incremental, not-so-big-bang
fashion. Obviously one of the requirements for that will be quicker
review turnaround and commit, so that there's time to build on a
previous patch...

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Before we settle on any dates I think we should have some discussion
about how we can shorten the period between feature freeze and beta,
which was far too long this time. Perhaps we need to be more aggressive
about what what makes the cut and what doesn't.

I think basically we need to redefine "feature freeze". The definition
we effectively used for the last couple of cycles was "if you've posted
a patch, even a slushy one, by the stated FF date, you make the cut".
This was compounded in the 8.3 cycle by reviewers (and I'm looking at
myself here) figuring that we could postpone reviewing patches until
after FF because the policy didn't require that they be in good shape
*before* that date. That would've worked OK if there were only a few
such patches, but we had a lot of big ones.

If we want a short FF-to-beta period then the criterion will have to be
that patches are either committed or darn near ready to commit on the FF
date. No springing mostly-done patches on the community a few days
before FF. And the reviewers will need to work harder on reviewing
stuff earlier, and committing before FF whenever possible. And we need
to be much more ready to bounce stuff that's not quite done, rather than
drag out the cycle to let it get finished.

No, it doesn't sound like any fun :-(. But this cycle was clearly
mismanaged. It's not productive to have a freeze this long.

[ thinks for a bit... ] A truly hard-nosed approach would be to define
FF as "if your patch isn't committed by the FF date, you lose". The
FF-to-beta delay then is only long enough to make sure we've documented
everything, written release notes, etc. I'm not sure this would be a
more pleasant way to work, as there'd be a heck of a lot of pressure on
the committers as the days tick down to FF. But it'd fix the scheduling
problem.

I'd settle for your earlier slightly porous formulation, at least for
one go round. We don't seem very fond of hard and fast rules as a
community (c.f. txid controversy) :-) The target should be to get to
beta within about a month from feature freeze, I think.

Maybe we need a better triage at the start of feature freeze which gives
candidates a preliminary review, at least enough to say "this is/is not
very close to being able to be applied". Anything that isn't, even if
submitted well before freeze, misses out. If reviewers are more active
then the candidate list would be small.

cheers

andrew

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Before we settle on any dates I think we should have some discussion
about how we can shorten the period between feature freeze and beta,
which was far too long this time. Perhaps we need to be more aggressive
about what what makes the cut and what doesn't.

[ thinks for a bit... ] A truly hard-nosed approach would be to define
FF as "if your patch isn't committed by the FF date, you lose". The
FF-to-beta delay then is only long enough to make sure we've documented
everything, written release notes, etc. I'm not sure this would be a
more pleasant way to work, as there'd be a heck of a lot of pressure on
the committers as the days tick down to FF. But it'd fix the scheduling
problem.

I actually don't disagree with anything you have to say but would like
to offer one other thought. Instead of a hard feature freeze, we offer a
continual development model. In short, we develop, review, commit etc..
until we feel a need to release.

Certainly we don't want to be releasing every 4 years but then again, in
reality 8.3 could have been released 6 months ago, should we decided,
hey... Tsearch2 and Hot.. well they aren't done so they get 8.4 and
perhaps because Tsearch2 and HOT are so cool, once they went in, even
though it is only 6 months later, it would be worth while to release
8.4. If we followed this model, we would be pushing 8.4 beta1 right now,
not 8.3.

Further the people wanting specific features of a specific release,
don't have to wait 12-15 months to get them.

I recognize this would be a *lot* easier if we didn't have the initdb
requirement but still... release early, release often.

I have really taken to the Ubuntu style of releasing. Every 6 months (or
so) they release. Every 2 years (or so) the LTS.

Is there potential for that here? I don't know, but it seems worth
exploring.

Sincerely,

Joshua D. Drake

On Mon, 22 Oct 2007, Tom Lane wrote:

If we want a short FF-to-beta period then the criterion will have to be
that patches are either committed or darn near ready to commit on the FF
date.

I think you're stuck with a certain amount of schedule delay regardless of
how mature code is at submission time when there's a large performance
component involved, rather than strictly a feature one. There was a lot
of that in 8.3, where it seemed to me the benchmarking and similar
quantifying of the true impact of the patch wasn't correlated so much with
the code quality at submission time. Good performance testing of any sort
takes a long time, there's only so many people who can do it, and having a
couple of different perspectives is almost mandatory to avoid optimizing
only for a particular application type. When you have a couple of such
things in the pool, you're not going to get a lot of work done on multiple
patches of that type in parallel, especially when there's any overlap
between them.

I personally think that shorting the minor release cycle time too far is
counterproductive anyway. From the DBA and system administrator
perspective, new version releases are a giant QA and maintenance mess.
Better to have less of them that each add larger features rather than a
more regular stream of small ones from where I'm sitting.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

Further the people wanting specific features of a specific release,
don't have to wait 12-15 months to get them.

I recognize this would be a *lot* easier if we didn't have the initdb
requirement but still... release early, release often.

I have really taken to the Ubuntu style of releasing. Every 6 months (or
so) they release. Every 2 years (or so) the LTS.

Is there potential for that here? I don't know, but it seems worth
exploring.

1x per year full version is well. And it's much better then in MySQL
or in Firebird. I thing so problem is in long patch queue. There are
lot of sleeping patches (enugh for 8.4 now), and isn't possible
transform to core it any short time (mainly with bombs like tsearch or
hot).

Pavel

On Mon, Oct 22, 2007 at 11:56:02PM -0400, Tom Lane wrote:

I'd rather encourage people to work in an incremental, not-so-big-bang
fashion. Obviously one of the requirements for that will be quicker
review turnaround and commit, so that there's time to build on a
previous patch...

From my outsider point of view the big difference is that the
probablility of $RANDOM_PATCH being reviewed during features freeze is
very much greater than at any other time. So the best way to get a
patch completed is to post it sometime before FF and after FF use the
subsequent feedback to improve it. If we can fix the disparity I think
most of the problems will go away...

Ofcourse, posting just prior FF doesn't help, but I think that's a
chicken/egg problem. People do what works.

Have a ncie day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

On Mon, 22 Oct 2007, Tom Lane wrote:

If we want a short FF-to-beta period then the criterion will have to be
that patches are either committed or darn near ready to commit on the FF
date.

I think you're stuck with a certain amount of schedule delay regardless of
how mature code is at submission time when there's a large performance
component involved, rather than strictly a feature one. There was a lot
of that in 8.3, where it seemed to me the benchmarking and similar
quantifying of the true impact of the patch wasn't correlated so much with
the code quality at submission time. Good performance testing of any sort
takes a long time, there's only so many people who can do it, and having a
couple of different perspectives is almost mandatory to avoid optimizing
only for a particular application type. When you have a couple of such
things in the pool, you're not going to get a lot of work done on multiple
patches of that type in parallel, especially when there's any overlap
between them.

I personally think that shorting the minor release cycle time too far is
counterproductive anyway. From the DBA and system administrator
perspective, new version releases are a giant QA and maintenance mess.
Better to have less of them that each add larger features rather than a
more regular stream of small ones from where I'm sitting.

+1. Shorter release cycles are maybe good for fancy GUI oriented
applications, but not so good for DBMS.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

[ thinks for a bit... ] A truly hard-nosed approach would be to define
FF as "if your patch isn't committed by the FF date, you lose". The
FF-to-beta delay then is only long enough to make sure we've documented
everything, written release notes, etc.

You're assuming nothing committed could possibly be broken. I think "normal"
feature freeze semantics are that you freeze adding new features so you can
get the features that are committed working properly.

While it's nice that we have such a high standard for the patches that are
committed it's also kind of limiting us. For example, I think it worked pretty
well when you committed HOT and then based on experience and discussion added
the per-page xid. Insisting on every patch being 100% perfected before it gets
committed makes it hard to collaborate since it limits the visibility of the
work in progress.

I do understand the concern that committing lots of broken or partial patches
will make it hard for others to work on unrelated work and make for lots of
work cleaning up the tree later. Tools like git/monotone/svk might help there.
But even with CVS there ought to be a better tradeoff than pushing all the
development into patches and requiring the CVS tree to be 100% perfected
complete patches. Working with patches over email is painful.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

I'd rather encourage people to work in an incremental, not-so-big-bang
fashion. Obviously one of the requirements for that will be quicker
review turnaround and commit, so that there's time to build on a
previous patch...

I'll second that. It's awfully hard to work in isolation building a larger and
larger patch for months without being sure that you're even on the right
track...

Note that quicker turnaround time doesn't have to mean actually doing reviews
faster. It just means not waiting until the patch is in release-ready state.
It's latency that's hurting us, not bandwidth...

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com