pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedRe: Beta schedule (was Roadmap for FE/BE protocol redesign)
2+ messages / 2 participants
[nested] [flat]
* Re: Beta schedule (was Roadmap for FE/BE protocol redesign)
@ 2003-03-11 05:32 Tom Lane <tgl@sss.pgh.pa.us>
2003-03-11 11:31 ` Re: Beta schedule (was Roadmap for FE/BE protocol redesign) Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 2+ messages in thread
From: Tom Lane @ 2003-03-11 05:32 UTC (permalink / raw)
To: Justin Clift <justin@postgresql.org>; +Cc: Bruce Momjian <pgman@candle.pha.pa.us>; pgsql-hackers@postgresql.org
Justin Clift <justin@postgresql.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
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Beta schedule (was Roadmap for FE/BE protocol redesign)
2003-03-11 05:32 Re: Beta schedule (was Roadmap for FE/BE protocol redesign) Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-03-11 11:31 ` Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 0 replies; 2+ messages in thread
From: Bruce Momjian @ 2003-03-11 11:31 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Justin Clift <justin@postgresql.org>; pgsql-hackers@postgresql.org
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@postgresql.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@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
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2003-03-11 11:31 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2003-03-11 05:32 Re: Beta schedule (was Roadmap for FE/BE protocol redesign) Tom Lane <tgl@sss.pgh.pa.us>
2003-03-11 11:31 ` Bruce Momjian <pgman@candle.pha.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox