Thread: Re: [pgsql-hackers] Daily digest v1.4988 (21 messages)
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
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
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
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
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, Pennsylvania19073
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, Pennsylvania19073
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