Josh Berkus wrote:
> I'll also say: if we can't make time-based releases work, we're probably
> dead as a project. MySQL and Ingres both tried feature-based releases,
> and look where they are now.
I think you're engaging in a bit of 'post hoc ergo propter hoc'
In any case, I think it's a false dichotomy. We always seem to treat
this as an all or nothing deal. But there is no reason that we must. We
could easily decide that one or two features were critical for the
release and everything else would have to make the time cut. For this
release those features would obviously be HS and SR. Obviously we could
could at some stage decide to cut our losses and run, as we did last
release (eventually). But I think that the idea that we should never at
least have a stated goal to have certain features in a given release is
a bit silly.
If you think we could put out this coming release without having HS +
SR, and not do significant damage to the project, I can only say I
In response to
pgsql-hackers by date
|Next:||From: Stefan Kaltenbrunner||Date: 2010-01-10 13:24:39|
|Subject: Re: [HACKERS] maintenance announcement for dekeni.postgresql.org
|Previous:||From: Robert Haas||Date: 2010-01-10 13:02:21|
|Subject: Re: damage control mode|