From: | Germán Poó-Caamaño <gpoo(at)ubiobio(dot)cl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Feature Freeze date for 8.4 |
Date: | 2007-10-24 13:14:45 |
Message-ID: | 1193231685.5668.24.camel@calcifer |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2007-10-23 at 19:24 -0400, Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
> > Mind you, I'm in favor of one. A new SCM would make some other development
> > tasks easier. However, I'm reluctant to open the can-of-worms which is the
> > "what SCM should we use" discussion again, and complicate something which
> > we seem to have consensus on.
>
> As near as I can tell, the arguments for a new SCM mostly apply to work
> which individual developers are doing outside the main tree. So, given
> the existence of stuff like git-cvsimport, I don't see a strong reason
> why anyone who wants to work that way can't already sync the core CVS
> with a local SCM-of-their-choice and get on with it.
According the proposal of reduce/avoid working with big patches, it
would help.
While it's even possible to handle separately a SCM and then send a big
patch, it's a pain merging it using CVS. And finally the history of that
patch is lost.
The workflow shouldn't change at all, but the tools can help to
improve the process of reviewing/merging patches. If that process
may improve, then a 'fixed' release schedule is even more possible,
IMVVHO.
--
Germán Poó Caamaño
Concepción - Chile
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-10-24 13:24:47 | Re: Feature Freeze date for 8.4 |
Previous Message | Gregory Stark | 2007-10-24 13:12:16 | Re: Feature Freeze date for 8.4 |