Re: [pgsql-hackers] Daily digest v1.4988 (21 messages)

Josh Berkus <josh@agliodbs.com> writes:

I thought we were trying to get away from a midsummer feature freeze, due to
the general lack of personnel in that season?
...
So I'd advocate either freezing in May, or in September.

Well, if you take the summer-vacation argument seriously, then nothing
will get done between May and September anyway, so we may as well freeze
in May ;-)

I'd be happy with saying June 1.

regards, tom lane

Tom,

Well, if you take the summer-vacation argument seriously, then nothing
will get done between May and September anyway, so we may as well freeze
in May ;-)

I'd be happy with saying June 1.

Hey, you and Bruce are the ones who'll get stuck with all the code checking if
nobody else is available, like last year. So it's your call.

Better, you should maybe check with the committers when people will be
available.

Also, what do you think of Simon's plan for a 2-stage feature freeze? Maybe
not so far apart ... maybe a month apart?

--
Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus wrote:

I thought we were trying to get away from a midsummer feature freeze,
due to the general lack of personnel in that season?

Better to do feature freeze with no one around than development or
release preparations with no one around, no?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Fri, 25 Feb 2005, Tom Lane wrote:

Josh Berkus <josh@agliodbs.com> writes:

I thought we were trying to get away from a midsummer feature freeze, due to
the general lack of personnel in that season?
...
So I'd advocate either freezing in May, or in September.

Well, if you take the summer-vacation argument seriously, then nothing
will get done between May and September anyway, so we may as well freeze
in May ;-)

I'd be happy with saying June 1.

I concur with Josh on this ... that kinda wastes the 'two months of
summer' when ppl are really sporatically around, so no really testing will
get done ... I'd rather see a Sept 1st feature freeze, once most ppl are
back from holidays and are a bit more steady ... it means those working on
the big features have a few extra months to hammer out the kinks, and
those testing are a bit more 'consistent/focused' then they are when they
are planning, or on, holidays ;)

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

On Fri, 25 Feb 2005, Josh Berkus wrote:

Also, what do you think of Simon's plan for a 2-stage feature freeze?
Maybe not so far apart ... maybe a month apart?

I missed that ... could you re-summarize?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

Marc,

I missed that ... could you re-summarize?

Sure, Simon proposed that we have a feature freeze for "major features" (like
bitmapped indexes and 2PC) before the feature freeze for "minor
features" (like new system views). The reason being that the major features
need a lot more code checking, and may affect the implementation of the minor
features.

I'd suggest a month interval.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus <josh@agliodbs.com> writes:

Also, what do you think of Simon's plan for a 2-stage feature freeze? Maybe
not so far apart ... maybe a month apart?

I didn't feel a need for it. It's true that the closer we get to
feature freeze, the smaller the patch you should expect to drop on us
sight unseen. Simon's proposal implies that this is a binary condition,
but it's really more of a continuous process. Another point is that
we've never wanted to discourage people from going full tilt right up
to feature freeze; if we say "you must have something credible X months
before freeze", that diminishes the value of free time that people might
have after that point.

regards, tom lane

On Fri, 25 Feb 2005, Peter Eisentraut wrote:

Josh Berkus wrote:

I thought we were trying to get away from a midsummer feature freeze,
due to the general lack of personnel in that season?

Better to do feature freeze with no one around than development or
release preparations with no one around, no?

I'd say the other way around ... at least when 'noone is around', one
person that is can still work on the feature they are working on ...
feature freeze when nobody around means the code stagnants since nobody is
around to test/give feedback ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

On Fri, 25 Feb 2005, Tom Lane wrote:

Josh Berkus <josh@agliodbs.com> writes:

Also, what do you think of Simon's plan for a 2-stage feature freeze? Maybe
not so far apart ... maybe a month apart?

I didn't feel a need for it. It's true that the closer we get to
feature freeze, the smaller the patch you should expect to drop on us
sight unseen. Simon's proposal implies that this is a binary condition,
but it's really more of a continuous process. Another point is that
we've never wanted to discourage people from going full tilt right up
to feature freeze; if we say "you must have something credible X months
before freeze", that diminishes the value of free time that people might
have after that point.

And, our 'feature freezes' have tended to be somewhat fluid ... its only
when we finally hit the beta cycle itself that things become locked in
stone ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

"Marc G. Fournier" <scrappy@postgresql.org> writes:

Josh Berkus <josh@agliodbs.com> writes:

I thought we were trying to get away from a midsummer feature freeze, due to
the general lack of personnel in that season?

I concur with Josh on this ... that kinda wastes the 'two months of
summer' when ppl are really sporatically around, so no really testing will
get done ... I'd rather see a Sept 1st feature freeze, once most ppl are
back from holidays and are a bit more steady ... it means those working on
the big features have a few extra months to hammer out the kinks, and
those testing are a bit more 'consistent/focused' then they are when they
are planning, or on, holidays ;)

The thing is, if we target feature freeze for September then I think
there is 0 chance of the 8.1 cycle being less than a year -- even with
a fairly short feature freeze and beta cycle you're getting into
December unless there are no slips at all. And we tried and failed to
release in December this last time; it's got the same
people-aren't-paying-attention problem as the summer.

If this were an ordinary devel cycle then I'd be fine with it running a
year, but I think we really do need to plan for a shorter than normal
cycle so we can clean up 8.0 kinks in a reasonably timely fashion.

Also, I'm unconvinced that we can't do post-feature-freeze cleanup
during the summer. If we have say a beta2 by the time September
comes, then people returning from vacation will have something to
beat on, and I think it will go well.

regards, tom lane

Tom Lane wrote:

"Marc G. Fournier" <scrappy@postgresql.org> writes:

Josh Berkus <josh@agliodbs.com> writes:

I thought we were trying to get away from a midsummer feature freeze, due to
the general lack of personnel in that season?

I concur with Josh on this ... that kinda wastes the 'two months of
summer' when ppl are really sporatically around, so no really testing will
get done ... I'd rather see a Sept 1st feature freeze, once most ppl are
back from holidays and are a bit more steady ... it means those working on
the big features have a few extra months to hammer out the kinks, and
those testing are a bit more 'consistent/focused' then they are when they
are planning, or on, holidays ;)

The thing is, if we target feature freeze for September then I think
there is 0 chance of the 8.1 cycle being less than a year -- even with
a fairly short feature freeze and beta cycle you're getting into
December unless there are no slips at all. And we tried and failed to
release in December this last time; it's got the same
people-aren't-paying-attention problem as the summer.

If this were an ordinary devel cycle then I'd be fine with it running a
year, but I think we really do need to plan for a shorter than normal
cycle so we can clean up 8.0 kinks in a reasonably timely fashion.

Let's see how much 8.0 cleanup we need. At this point I haven't seen
any major things needing cleanup.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

If this were an ordinary devel cycle then I'd be fine with it running a
year, but I think we really do need to plan for a shorter than normal
cycle so we can clean up 8.0 kinks in a reasonably timely fashion.

Let's see how much 8.0 cleanup we need. At this point I haven't seen
any major things needing cleanup.

However, people are asking us for a schedule target now; "wait and see"
isn't the answer they need. My feeling is that we should bet on there
being some issues, rather than bet on there not being any.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

If this were an ordinary devel cycle then I'd be fine with it running a
year, but I think we really do need to plan for a shorter than normal
cycle so we can clean up 8.0 kinks in a reasonably timely fashion.

Let's see how much 8.0 cleanup we need. At this point I haven't seen
any major things needing cleanup.

However, people are asking us for a schedule target now; "wait and see"
isn't the answer they need. My feeling is that we should bet on there
being some issues, rather than bet on there not being any.

Uh, they want to know now? My feeling is that if there were major
issues, we would have heard about them already --- it has been over a
month since 8.0. It has been a long time since we have had to push out
a major to fix a hard problem in the previous major.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian said:

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

If this were an ordinary devel cycle then I'd be fine with it
running a year, but I think we really do need to plan for a shorter
than normal cycle so we can clean up 8.0 kinks in a reasonably
timely fashion.

Let's see how much 8.0 cleanup we need. At this point I haven't
seen any major things needing cleanup.

However, people are asking us for a schedule target now; "wait and
see" isn't the answer they need. My feeling is that we should bet on
there being some issues, rather than bet on there not being any.

Uh, they want to know now?

YES! Yes yes yes! I try to plan my time, and the feature freeze data is very
important in that planning.

Also, regardless of the issues Tom raised, 18 months is too long a release
cycle, IMNSHO. If you do that and you take the time from feature freeze of
release n to release date of release n+1, a developer could wait 2 years
from the date of submission to see his/her feature in a release. 2 years is
an eternity in this game. Just my $0.02 worth.

cheers

andrew

YES! Yes yes yes! I try to plan my time, and the feature freeze data is very
important in that planning.

This is also important for people considering sponsoring developers.

Also, regardless of the issues Tom raised, 18 months is too long a release
cycle, IMNSHO. If you do that and you take the time from feature freeze of
release n to release date of release n+1, a developer could wait 2 years
from the date of submission to see his/her feature in a release. 2 years is
an eternity in this game. Just my $0.02 worth.

I think it depends on the level of features being worked on. Look
at how long there is between Oracle major releases or **GASP** Mysql?

I think it is silly to have to wait 18 months for a new release
of say plPgsql of plPerl, new functions or maybe a new group by
capability... This should be able to be in . releases.

However... PITR, Savepoints? Those are major coding efforts. It
makes sense that they would take that long.

Sincerely,

Joshua D. Drake

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL