Tom,
> This seems pretty entirely orthogonal to the commit-fest proposal.
> I see no reason to think that snapshots taken at those times would
> be any better than any other nightly snapshot, nor any reason
> to memorialize them in an archive.
I can see that. And it would be pretty hard to keep
On 10/25/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
> Huh, I hadn't heard of that either. The Debian package patchutils says it was
> downloaded from:
>
> http://cyberelk.net/tim/data/patchutils
>
> What's really cool is that patchutils also appears to have the utility I've
> been looking for for
Brendan Jurd wrote:
On 10/24/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Brendan Jurd escribió:
Really? I just started playing around with git, and the output from git
diff produced the same kind of diff file I would normally get from `svn
di`
... which is a unified diff.
or `cvs di -c`.
On Wed, Oct 24, 2007 at 02:18:42PM -0300, Alvaro Herrera wrote:
> [EMAIL PROTECTED] wrote:
> > On Wed, Oct 24, 2007 at 02:32:13PM +0200, Martijn van Oosterhout wrote:
> > > On Tue, Oct 23, 2007 at 02:39:43PM -0700, David Fetter wrote:
> > > > The one below is already available, so we don't have to
[EMAIL PROTECTED] wrote:
> On Wed, Oct 24, 2007 at 02:32:13PM +0200, Martijn van Oosterhout wrote:
> > On Tue, Oct 23, 2007 at 02:39:43PM -0700, David Fetter wrote:
> > > The one below is already available, so we don't have to do a "flag
> > > day" with it.
> > >
> > > http://repo.or.cz/w/PostgreS
* Tom Lane <[EMAIL PROTECTED]> [071024 08:45]:
> Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> > * Brendan Jurd <[EMAIL PROTECTED]> [071024 01:41]:
> >> How up to date is the Git repos? Does it pull individual commits from
> >> CVS, or does it resync the whole history periodically? If so, what's
>
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> You can use "filterdiff -v --format=context".
>
> Cool, I'll have to get a copy of that.
Huh, I hadn't heard of that either. The Debian package patchutils says it was
downloaded from:
http://cyberelk.net/t
Tom Lane wrote:
> [ chewing on this a bit... ] The curious thing about that is that
> despite this being designed to be a short release cycle, we ended up
> landing a bunch of major patches that weren't on the radar screen at
> all at the start of the cycle. This suggests to me that there's
> som
Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > Anyway, is there anyone who thinks the "cycle the queue every 6 weeks or 2
> > months or suitable short period" is a *bad* idea? It might be hard to
> > pull
> > off, but we won't know until we try.
>
> It seems worth a try --- we
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > I'm fairly resistant to putting less-than-ready code in the tree, I must
> > say.
>
> Me too, at least if "less than ready" means "unstable". The committed
> code has to always be solid enough to let everybody continue working on
>
Marko Kreen wrote:
> On 10/24/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > > As we seem discussing developement in general, there is one
> > > obstacle in the way of individual use of DSCMs - context diff
> > > format as only one accepted.
> >
> > Well,
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> You can use "filterdiff -v --format=context".
Cool, I'll have to get a copy of that.
> Because it's easy to convert from one to another, I think the unified
> vs. context diff issue is a non-issue.
Fair enough then; we should just change the polic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Oct 24, 2007 at 02:32:13PM +0200, Martijn van Oosterhout wrote:
> On Tue, Oct 23, 2007 at 02:39:43PM -0700, David Fetter wrote:
> > The one below is already available, so we don't have to do a "flag
> > day" with it.
> >
> > http://repo.or.cz/
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> On Wed, Oct 24, 2007 at 09:24:47AM -0400, Tom Lane wrote:
>>> I don't recall that we've rejected any patches lately just because they
>>> were unidiffs. But I'd be sad if a large fraction of incoming patches
>>> started to be unidiff
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Wed, Oct 24, 2007 at 09:24:47AM -0400, Tom Lane wrote:
>> I don't recall that we've rejected any patches lately just because they
>> were unidiffs. But I'd be sad if a large fraction of incoming patches
>> started to be unidiffs.
> We bounce them b
Marko Kreen wrote:
On 10/24/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Marko Kreen" <[EMAIL PROTECTED]> writes:
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted.
Well, that's not
On 10/24/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > As we seem discussing developement in general, there is one
> > obstacle in the way of individual use of DSCMs - context diff
> > format as only one accepted.
>
> Well, that's not a hard-and-fast rule,
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
>> As we seem discussing developement in general, there is one
>> obstacle in the way of individual use of DSCMs - context diff
>> format as only one accepted.
>
> Well, that's not a hard-and-fast rule, just a prefe
On Wed, 2007-10-24 at 14:32 +0200, Martijn van Oosterhout wrote:
> On Tue, Oct 23, 2007 at 02:39:43PM -0700, David Fetter wrote:
> > The one below is already available, so we don't have to do a "flag
> > day" with it.
> >
> > http://repo.or.cz/w/PostgreSQL.git
>
> As someone who hasn't used GIT:
On Wed, Oct 24, 2007 at 09:24:47AM -0400, Tom Lane wrote:
> I don't recall that we've rejected any patches lately just because they
> were unidiffs. But I'd be sad if a large fraction of incoming patches
> started to be unidiffs.
We bounce them back to the author pretty m uch every time with "con
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> As we seem discussing developement in general, there is one
> obstacle in the way of individual use of DSCMs - context diff
> format as only one accepted.
Well, that's not a hard-and-fast rule, just a preference. At least for
me, unidiff is vastly harde
On Tue, 2007-10-23 at 19:24 -0400, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> 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
"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes:
> On Tue, Oct 23, 2007 at 02:39:43PM -0700, David Fetter wrote:
>> The one below is already available, so we don't have to do a "flag
>> day" with it.
>>
>> http://repo.or.cz/w/PostgreSQL.git
>
> As someone who hasn't used GIT: if I have a modi
Josh Berkus wrote:
Folks,
You are way ahead of us here. And my vote *still* goes to Mercurial, if
we're picking SCMs.
Will a new SCM actually make this easier, or are people just using it as an
excuse?
We use mercurial here at work, having switched to it recently, and while
I
On Wed, 2007-10-24 at 08:33 -0300, Alvaro Herrera wrote:
> David Fetter wrote:
>
> > I'm not picking a DSCM. I'm saying we already have tools in place for
> > a DSCM *without* having a "flag day." If Mercurial has a similar
> > migration/legacy support path, then by all means, let's try that out
Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> * Brendan Jurd <[EMAIL PROTECTED]> [071024 01:41]:
>> How up to date is the Git repos? Does it pull individual commits from
>> CVS, or does it resync the whole history periodically? If so, what's
>> the lag?
> It's updated hourly, which is the same rat
On Tue, Oct 23, 2007 at 02:39:43PM -0700, David Fetter wrote:
> The one below is already available, so we don't have to do a "flag
> day" with it.
>
> http://repo.or.cz/w/PostgreSQL.git
As someone who hasn't used GIT: if I have a modified CVS tree from some time
back (>1 year) can I use this to m
* Brendan Jurd <[EMAIL PROTECTED]> [071024 01:41]:
> How up to date is the Git repos? Does it pull individual commits from
> CVS, or does it resync the whole history periodically? If so, what's
> the lag?
It's updated hourly, which is the same rate the public CVS is updated.
> An important pa
On 10/24/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Brendan Jurd escribió:
> > Really? I just started playing around with git, and the output from
> > git diff produced the same kind of diff file I would normally get from
> > `svn di`
>
> ... which is a unified diff.
>
> > or `cvs di -c`.
>
>
Alvaro Herrera write:
Marko Kreen escribió:
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted. Both leading DSCMs - GIT and Mercurial
do not support it.
Hmm, in Subversion you can specify a se
Brendan Jurd escribió:
> > As we seem discussing developement in general, there is one
> > obstacle in the way of individual use of DSCMs - context diff
> > format as only one accepted. Both leading DSCMs - GIT and Mercurial
> > do not support it.
> >
>
> Really? I just started playing around wi
> As we seem discussing developement in general, there is one
> obstacle in the way of individual use of DSCMs - context diff
> format as only one accepted. Both leading DSCMs - GIT and Mercurial
> do not support it.
>
Really? I just started playing around with git, and the output from
git diff
Marko Kreen escribió:
> As we seem discussing developement in general, there is one
> obstacle in the way of individual use of DSCMs - context diff
> format as only one accepted. Both leading DSCMs - GIT and Mercurial
> do not support it.
Hmm, in Subversion you can specify a separate diff comman
David Fetter wrote:
> I'm not picking a DSCM. I'm saying we already have tools in place for
> a DSCM *without* having a "flag day." If Mercurial has a similar
> migration/legacy support path, then by all means, let's try that out,
> too. :)
There's at least on Mercurial repo, here:
http://www.
On 10/24/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 24, 2007 at 11:04:34AM +0300, Marko Kreen wrote:
> > On 10/24/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> > > > The main problem with using Git on a much larger scale is that there's
> > > > still limited ability to use it o
On Wed, Oct 24, 2007 at 11:04:34AM +0300, Marko Kreen wrote:
> On 10/24/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> > > The main problem with using Git on a much larger scale is that there's
> > > still limited ability to use it on Win32. Google is working on that:
> > > http://code.google.co
On 10/24/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> > The main problem with using Git on a much larger scale is that there's
> > still limited ability to use it on Win32. Google is working on that:
> > http://code.google.com/p/msysgit/ but it's not quite there yet; there's
> > also a partial
On 10/24/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Josh Berkus <[EMAIL PROTECTED]> 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, an
> The main problem with using Git on a much larger scale is that there's
> still limited ability to use it on Win32. Google is working on that:
> http://code.google.com/p/msysgit/ but it's not quite there yet; there's
> also a partial MinGW port.
IIRC the official word from the git people is
On Tue, 2007-10-23 at 19:42 -0400, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > Plus, for the developers and other people who really need to be
> > bleeding-edge, this new plan would result in less-unstable snapshots every
> > 2 months with defined feature sets which someone who
On Tue, 2007-10-23 at 16:19 -0700, Josh Berkus wrote:
> > Maybe. I'm looking for ways to increase the amount of development time
> > we have compared with time releasing. If we release twice as often, we
> > won't get twice the beta test contribution from everybody, so our code
> > will be less ro
On Tue, Oct 23, 2007 at 07:24:21PM -0400, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> 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
On 10/24/07, Greg Smith <[EMAIL PROTECTED]> wrote:
> 1) Make a converted copy of the existing CVS repository
> 2) Keep the mirrored repo up to date with new commits
> 3) Provide working guidelines so that developers can use the new VCS to
> build local patches and improve their productivity
> 4) Ge
On Tue, 23 Oct 2007, David Fetter wrote:
If Mercurial has a similar migration/legacy support path, then by all
means, let's try that out, too.
There's an import tool at http://hg.beekhof.net/hg/cvs-import but the
experience of the Mozilla project suggests it's on the buggy and slow side
for
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> It might be worth applying a simple tag (but not a branch) at the end
> (and maybe also at the start) of each checkpoint/fest/whatever
Perhaps, though of course one could easily enough pull a CVS snapshot by
date instead (especially if we stick to a pr
Tom Lane wrote:
Now to the extent that regular commit-fests keep patch development
more closely aligned with the mainline CVS, the fest proposal might
indirectly alleviate your pain. But I'd think that snaps taken
*after* the fests would be the best for that, as they'd be closer
to what any su
Josh Berkus <[EMAIL PROTECTED]> writes:
> If we had milestone snapshots of each 2 months ... probably just before
> each commit-fest ... and kept them available on ftp.postgresql.org until
> official beta, then it would make it easier for testers to have a common
> point of reference to work wit
Tom,
> Since there are always bugs, and we're certainly not going to schedule a
> round of formal beta testing right after each commit-fest, I should
> think that tarballs made right after a commit-fest would be particularly
> unlikely to be good candidates for non-developer use.
>
> (Actually, it
Josh Berkus <[EMAIL PROTECTED]> writes:
> Plus, for the developers and other people who really need to be
> bleeding-edge, this new plan would result in less-unstable snapshots every
> 2 months with defined feature sets which someone who wanted to run them at
> their own risk could. Which would
Josh Berkus <[EMAIL PROTECTED]> 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 consens
Simon,
> Maybe. I'm looking for ways to increase the amount of development time
> we have compared with time releasing. If we release twice as often, we
> won't get twice the beta test contribution from everybody, so our code
> will be less robust, which will hurt us in the long run.
I don't thin
Joshua D. Drake wrote:
>
> We develop and commit like normal *until* the community feels there is
> enough for release. Then we announce a feature freeze.
I think you just described what will happen in reality regardless
of whatever is decided to be an official "plan". :) I don't
think that's n
On Tue, 2007-10-23 at 09:28 -0700, Joshua D. Drake wrote:
> On Tue, 23 Oct 2007 09:29:58 -0400
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > I'd suggest we have multiple checkpoints during the cycle.
> > > Checkpoint is a "patch queue blitz" where we sto
Folks,
> You are way ahead of us here. And my vote *still* goes to Mercurial, if
> we're picking SCMs.
Will a new SCM actually make this easier, or are people just using it as an
excuse?
Mind you, I'm in favor of one. A new SCM would make some other development
tasks easier. However, I'm relu
On Tue, Oct 23, 2007 at 06:19:42PM -0400, Andrew Dunstan wrote:
> David Fetter wrote:
> >On Tue, Oct 23, 2007 at 04:59:51PM -0400, Chris Browne wrote:
> >>[EMAIL PROTECTED] (Tom Lane) writes:
> >>>Simon Riggs <[EMAIL PROTECTED]> writes:
> >>>
> I'd suggest we have multiple checkpoints dur
Tom,
> Personally I feel every six weeks would be too short: we'd be talking
> only a month of work between commit-fests. I like a two-month cycle
> partly because it wouldn't rotate relative to the calendar: we'd always
> know that the first half of every odd-numbered month, or something like
>
David Fetter wrote:
On Tue, Oct 23, 2007 at 04:59:51PM -0400, Chris Browne wrote:
[EMAIL PROTECTED] (Tom Lane) writes:
Simon Riggs <[EMAIL PROTECTED]> writes:
I'd suggest we have multiple checkpoints during the cycle.
Checkpoint is a "patch queue blitz" where we stop developin
Tom Lane wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
Anyway, is there anyone who thinks the "cycle the queue every 6 weeks or 2
months or suitable short period" is a *bad* idea? It might be hard to pull
off, but we won't know until we try.
It seems worth a try --- we can certai
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I'm fairly resistant to putting less-than-ready code in the tree, I must
say.
Me too, at least if "less than ready" means "unstable". The committed
code has to always be solid enough to let everybody continue working on
thei
Josh Berkus <[EMAIL PROTECTED]> writes:
> Anyway, is there anyone who thinks the "cycle the queue every 6 weeks or 2
> months or suitable short period" is a *bad* idea? It might be hard to pull
> off, but we won't know until we try.
It seems worth a try --- we can certainly abandon it easily i
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I'm fairly resistant to putting less-than-ready code in the tree, I must
> say.
Me too, at least if "less than ready" means "unstable". The committed
code has to always be solid enough to let everybody continue working on
their own bits. However, in
On Tue, Oct 23, 2007 at 04:59:51PM -0400, Chris Browne wrote:
> [EMAIL PROTECTED] (Tom Lane) writes:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> >> I'd suggest we have multiple checkpoints during the cycle.
> >> Checkpoint is a "patch queue blitz" where we stop developing and
> >> reduce the queu
[EMAIL PROTECTED] (Tom Lane) writes:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>> I'd suggest we have multiple checkpoints during the cycle. Checkpoint is
>> a "patch queue blitz" where we stop developing and reduce the queue to
>> nothing. Perhaps a two-week period where everybody helps reduce the
Gregory Stark wrote:
> "Josh Berkus" <[EMAIL PROTECTED]> writes:
>
> > All,
> >
> >> We could release "alpha" releases. But that assumes that these reviews
> >> actually result in stuff getting committed even if they're not 100%
> >> complete. I think that would be a good thing but I don't think e
Gregory Stark wrote:
The problem I ran into was that by the time I had them all wrapped up major
new commits to the CVS tree made it uninteresting to benchmark the snapshot I
had.
That's going to be a problem with any snapshot approach. For the most
part, interesting patches are going to
Greg,
> The problem I ran into was that by the time I had them all wrapped up major
> new commits to the CVS tree made it uninteresting to benchmark the snapshot
> I had. Also I think a new version of HOT had been posted.
Yeah, that's exactly what I was thinking of. The Sun benchmarking folks wo
"Josh Berkus" <[EMAIL PROTECTED]> writes:
> All,
>
>> We could release "alpha" releases. But that assumes that these reviews
>> actually result in stuff getting committed even if they're not 100%
>> complete. I think that would be a good thing but I don't think everyone
>> else agrees. Also, not a
Gregory Stark wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>
>> I know I just love it when a customer breaks something and I ask what
>> changed and it is 56 different things ;)
>>
>> My question is.. with a checkpoint every 2 months, would it make it
>> very easy to release every 6 (or
All,
> We could release "alpha" releases. But that assumes that these reviews
> actually result in stuff getting committed even if they're not 100%
> complete. I think that would be a good thing but I don't think everyone
> else agrees. Also, not all reviewers are committers.
This is what I'm thi
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> I know I just love it when a customer breaks something and I ask what
> changed and it is 56 different things ;)
>
> My question is.. with a checkpoint every 2 months, would it make it
> very easy to release every 6 (or 4 or 3 or 9) months? I am not
On Tue, 23 Oct 2007 12:45:14 -0400
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
>
> Joshua D. Drake wrote:
> > We develop and commit like normal *until* the community feels there
> > is enough for release. Then we announce a feature freeze.
> >
> >
>
> No, I think this is hopeless on several
Joshua D. Drake wrote:
We develop and commit like normal *until* the community feels there is
enough for release. Then we announce a feature freeze.
No, I think this is hopeless on several grounds. First, it increases
uncertainty. People need to be able to work towards a target. Second,
On 10/24/07, David Fetter <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 23, 2007 at 09:39:39AM +0100, Gregory Stark wrote:
> >
> > "Tom Lane" <[EMAIL PROTECTED]> writes:
> >
> > > I'd rather encourage people to work in an incremental,
> > > not-so-big-bang fashion. Obviously one of the requirements for
On Tue, 23 Oct 2007 09:29:58 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I'd suggest we have multiple checkpoints during the cycle.
> > Checkpoint is a "patch queue blitz" where we stop developing and
> > reduce the queue to nothing. Perhaps a two-week p
On Tue, Oct 23, 2007 at 09:39:39AM +0100, Gregory Stark wrote:
>
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > I'd rather encourage people to work in an incremental,
> > not-so-big-bang fashion. Obviously one of the requirements for
> > that will be quicker review turnaround and commit, so that
On Tue, 23 Oct 2007 11:00:59 +0200
Rafael Martinez <[EMAIL PROTECTED]> wrote:
> Tatsuo Ishii wrote:
>
> >
> > +1. Shorter release cycles are maybe good for fancy GUI oriented
> > applications, but not so good for DBMS.
> > --
>
> We are always 1 year back the main release. We are testing and pl
On Tue, 23 Oct 2007 17:28:14 +0900 (JST)
Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> > On Mon, 22 Oct 2007, Tom Lane wrote:
> > I personally think that shorting the minor release cycle time too
> > far is counterproductive anyway. From the DBA and system
> > administrator perspective, new version
Tom, all:
> > I'd suggest we have multiple checkpoints during the cycle. Checkpoint is
> > a "patch queue blitz" where we stop developing and reduce the queue to
> > nothing. Perhaps a two-week period where everybody helps reduce the
> > queue, not just Tom and Bruce. Every outstanding patch gets
Simon Riggs <[EMAIL PROTECTED]> writes:
> I'd suggest we have multiple checkpoints during the cycle. Checkpoint is
> a "patch queue blitz" where we stop developing and reduce the queue to
> nothing. Perhaps a two-week period where everybody helps reduce the
> queue, not just Tom and Bruce. Every ou
On Mon, 2007-10-22 at 12:37 -0700, Josh Berkus wrote:
> Simon,
>
> > We can issue a provisional date. We could also say "at least 6 months
> > after release date of 8.3". I'm sure there's other options too.
>
> I'm going to suggest 4 months after 8.3. 8.3 was supposed to be a *short*
> release
On Mon, 2007-10-22 at 23:36 -0400, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Before we settle on any dates I think we should have some discussion
> > about how we can shorten the period between feature freeze and beta,
> > which was far too long this time. Perhaps we need t
On Tue, 2007-10-23 at 11:00 +0200, Rafael Martinez wrote:
> We are always 1 year back the main release. We are testing and planing
> the move to 8.2 now, and it won't happen until desember. In a 6 month
> cycle we will have to jump over every second release.
We here are also just in the process of
Tatsuo Ishii wrote:
>
> +1. Shorter release cycles are maybe good for fancy GUI oriented
> applications, but not so good for DBMS.
> --
I agree, sure it will be great to have even more and new features as
soon as possible, but not if the quality of the final product decrease.
The most important
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I'd rather encourage people to work in an incremental, not-so-big-bang
> fashion. Obviously one of the requirements for that will be quicker
> review turnaround and commit, so that there's time to build on a
> previous patch...
I'll second that. It's awf
"Tom Lane" <[EMAIL PROTECTED]> writes:
> [ thinks for a bit... ] A truly hard-nosed approach would be to define
> FF as "if your patch isn't committed by the FF date, you lose". The
> FF-to-beta delay then is only long enough to make sure we've documented
> everything, written release notes, etc
> On Mon, 22 Oct 2007, Tom Lane wrote:
>
> > If we want a short FF-to-beta period then the criterion will have to be
> > that patches are either committed or darn near ready to commit on the FF
> > date.
>
> I think you're stuck with a certain amount of schedule delay regardless of
> how matur
> Further the people wanting specific features of a specific release,
> don't have to wait 12-15 months to get them.
>
> I recognize this would be a *lot* easier if we didn't have the initdb
> requirement but still... release early, release often.
>
> I have really taken to the Ubuntu style of rele
On Mon, Oct 22, 2007 at 11:56:02PM -0400, Tom Lane wrote:
> I'd rather encourage people to work in an incremental, not-so-big-bang
> fashion. Obviously one of the requirements for that will be quicker
> review turnaround and commit, so that there's time to build on a
> previous patch...
From my o
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Before we settle on any dates I think we should have some discussion
about how we can shorten the period between feature freeze and beta,
which was far too long this time. Perhaps we need to be more aggressive
about what what make
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Before we settle on any dates I think we should have some discussion
about how we can shorten the period between feature freeze and beta,
which was far too long this time. Perhaps we need to be more aggressive
about what what makes the
On Mon, 22 Oct 2007, Tom Lane wrote:
If we want a short FF-to-beta period then the criterion will have to be
that patches are either committed or darn near ready to commit on the FF
date.
I think you're stuck with a certain amount of schedule delay regardless of
how mature code is at submiss
Chris Browne <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Josh Berkus) writes:
>> In fact, I could see doing a "no-catalog-changes, no major patches we don't
>> already know about, 6-month release". It would reset our cycle and get
>> PL/proxy, DSM, clustered indexes, etc. out the door. It
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Before we settle on any dates I think we should have some discussion
> about how we can shorten the period between feature freeze and beta,
> which was far too long this time. Perhaps we need to be more aggressive
> about what what makes the cut and w
[EMAIL PROTECTED] (Josh Berkus) writes:
> Simon,
>
>> We can issue a provisional date. We could also say "at least 6 months
>> after release date of 8.3". I'm sure there's other options too.
>
> I'm going to suggest 4 months after 8.3. 8.3 was supposed to be a *short*
> release so that we could m
"Tom Lane" <[EMAIL PROTECTED]> writes:
> In point of fact, the big patches that aren't in 8.3 were rejected
> because they weren't ready. They won't get into 8.4, either, unless
> someone does a lot more work on them. So I don't follow this idea
> of how we have a pre-loaded queue of good stuff
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>> Ah, you mean like we planned for 8.0 and failed, then for 8.1 and
>> failed, then for 8.2 and failed, then for 8.3 and failed? I can
>> definitely support that idea.
>>
> As I recall 8.0 and 8.1 actually
On Mon, 22 Oct 2007 16:47:41 -0300
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Josh Berkus wrote:
>
> > In fact, I could see doing a "no-catalog-changes, no major patches
> > we don't already know about, 6-month release". It would reset our
> > cycle and get PL/proxy, DSM, clustered indexes, etc
Josh Berkus wrote:
So my thought is, shoot for a short release so that we can get away from
summer consolidations and December releases, and extend the cycle if
someone dumps another 50,000 lines of attractive patches on us.
Before we settle on any dates I think we should have some disc
Josh Berkus wrote:
> In fact, I could see doing a "no-catalog-changes, no major patches we don't
> already know about, 6-month release". It would reset our cycle and get
> PL/proxy, DSM, clustered indexes, etc. out the door. It could mean
> turning away patches which look attractive, though,
Simon,
> We can issue a provisional date. We could also say "at least 6 months
> after release date of 8.3". I'm sure there's other options too.
I'm going to suggest 4 months after 8.3. 8.3 was supposed to be a *short*
release so that we could move our calendar around. HOT and some of the
oth
1 - 100 of 103 matches
Mail list logo
