From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Justin Clift <justin(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Beta schedule (was Roadmap for FE/BE protocol redesign) |
Date: | 2003-03-11 11:31:26 |
Message-ID: | 200303111131.h2BBVQd25189@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-interfaces |
I agree, let's not wait for specific features. The issue was whether we
had enough significant features done for a release --- I didn't think we
did, so I am saying, let's get more features, rather than let's get
feature X.
As we fill in missing features, there will be less must-have features to
add, so we are left with continuing with our present release pace or
releasing less frequently with the same number of feature additions.
---------------------------------------------------------------------------
Tom Lane wrote:
> Justin Clift <justin(at)postgresql(dot)org> writes:
> > With 7.1/7.2, Tom mentioned us being delayed because specific features
> > we were waiting for became dependant on one person.
>
> > Would it be feasible to investigate approaches for having the Win32 and
> > PITR work be shared amongst a few very-interested volunteers, so that
> > people can cover for each other's downtime?
>
> It would certainly be good to bring as much manpower to bear on those
> problems as we can. But that doesn't really address my concern: if the
> schedule is defined as "we go beta when feature X is done", then no one
> who's working on stuff other than feature X knows how to plan their
> time. The only fair way to run the project is "we go beta at time T";
> that way everyone knows what they need to shoot for and can plan
> accordingly.
>
> I don't mind setting the planned time T on the basis of what we think
> it will take for certain popular feature X's to be done. But if the
> guys working on X aren't done at T, it's not fair to everyone else to
> hold our breaths waiting for them to be done at T-plus-who-knows-what.
>
> I don't really have any sympathy for the argument that "it won't be a
> compelling release if we don't have feature X". If the release isn't
> compelling for someone, they don't have to upgrade; they can wait for
> the next release. The folks who *are* eager for what's been gotten done
> will be glad of having a release now rather than N months from now.
> And do I need to point out that "it runs on Windoze" is not of
> earth-shattering importance for everyone?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2003-03-11 13:34:11 | Re: Roadmap for FE/BE protocol redesign |
Previous Message | Hiroshi Inoue | 2003-03-11 10:07:07 | Re: Roadmap for FE/BE protocol redesign |
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Alford | 2003-03-11 12:11:55 | Embedded C SQL Error -600 |
Previous Message | Hiroshi Inoue | 2003-03-11 10:07:07 | Re: Roadmap for FE/BE protocol redesign |