Tom,
As a proposal: feature freeze maybe early summer (June or July), beta
maybe Aug/Sep, final as always "when it's ready" (maybe Oct/Nov with
a good tailwind).
I thought we were trying to get away from a midsummer feature freeze, due to
the general lack of personnel in that season? I can tell you that, while
I'm probably the least critical person for a feature freeze, I will be
unavailable for anything development-related from July 10 to August 6th.
And at least a dozen PG people will be presenting at OSCON, which means that
their attention will be divided in the last week of July. And there's a
bunch of European conventions in June, for that matter.

So I'd advocate either freezing in May, or in September.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Search Discussions

  • Tom Lane at Feb 25, 2005 at 5:59 pm

    Josh Berkus 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
  • Josh Berkus at Feb 25, 2005 at 6:02 pm
    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
  • Marc G. Fournier at Feb 25, 2005 at 6:11 pm

    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
  • Josh Berkus at Feb 25, 2005 at 6:18 pm
    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
  • Tom Lane at Feb 25, 2005 at 6:19 pm

    Josh Berkus 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
  • Marc G. Fournier at Feb 25, 2005 at 6:33 pm

    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 at Feb 25, 2005 at 6:10 pm

    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
  • Tom Lane at Feb 25, 2005 at 7:34 pm

    "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
  • Bruce Momjian at Feb 25, 2005 at 9:59 pm

    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
  • Tom Lane at Feb 25, 2005 at 10:04 pm

    Bruce Momjian 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
  • Bruce Momjian at Feb 25, 2005 at 10:09 pm

    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
  • Andrew Dunstan at Feb 26, 2005 at 1:03 pm

    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
  • Joshua D. Drake at Feb 26, 2005 at 6:49 pm

    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
  • Peter Eisentraut at Feb 25, 2005 at 6:05 pm

    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?
  • Marc G. Fournier at Feb 25, 2005 at 6:21 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedFeb 25, '05 at 5:48p
activeFeb 26, '05 at 6:49p
posts16
users7
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase