Robert,

> Well, I suppose that history has shown that waiting on specific features
> causes trouble with postgresql development, but I don't see why a
> release can't be based around waiting for feature x as long as feature x
> is being actively worked on by trusted developers who have an endgame in
> sight.

Ultimately, this is one of those "technical" vs. "marketing" questions ... 
whether to release now with a bunch of back-end features that the current 
users want, or to release later and include the features that we said were 
going to be in 7.4.   And PostgreSQL is a technical project, not a marketing 
one.  

I know that, given MySQL's attempts to squeeze PostgreSQL out of the market, 
that there is a lot of desire to include at least one "killer feature" in 
each release to grab press coverage.   But the PostgreSQL project can't let 
our technical decisions be governed by our PR, or we *become* MySQL.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

Fri, 20 Jun 2003 08:21:55 -0700
Josh Berkus <josh@agliodbs.com>
Re: Two weeks to feature freeze 
On Fri, 2003-06-20 at 11:21, Josh Berkus wrote:
> Robert,
> 
> > Well, I suppose that history has shown that waiting on specific features
> > causes trouble with postgresql development, but I don't see why a
> > release can't be based around waiting for feature x as long as feature x
> > is being actively worked on by trusted developers who have an endgame in
> > sight.
> 
> Ultimately, this is one of those "technical" vs. "marketing" questions ... 

absolutely not. this is a x style of development vs. y style of
development discussion. many many projects, commercial and open source,
use a style of releasing based on features included in a given version.
In fact I'd be willing to say that the majority of open source projects
work this way, since open source projects generally aren't beholden to
release dates, giving developers the time they need to get specific
features done and release them when they are ready.  as i prefaced in my
message, "history has shown us that waiting on specific features causes
trouble with postgresql development", but that doesn't mean we should
act as if this style of development doesn't exist.  

> whether to release now with a bunch of back-end features that the current 
> users want, or to release later and include the features that we said were 
> going to be in 7.4.   And PostgreSQL is a technical project, not a marketing 
> one.  
> 

right, which is why core/hackers will decide both what gets into each
releases and when it's released.  since i'm not outpacing tom or bruce
in my patch submissions i don't expect them to bend to my whims, but as
someone who follows and participates in postgresql development
regardless of an marketing aspects, i don't mind pointing out
alternatives.

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


20 Jun 2003 11:41:08 -0400
Robert Treat <xzilla@users.sourceforge.net>
Re: Two weeks to feature freeze
Robert,

> absolutely not. this is a x style of development vs. y style of
> development discussion. many many projects, commercial and open source,
> use a style of releasing based on features included in a given version.
> In fact I'd be willing to say that the majority of open source projects
> work this way, since open source projects generally aren't beholden to
> release dates, giving developers the time they need to get specific
> features done and release them when they are ready.  as i prefaced in my
> message, "history has shown us that waiting on specific features causes
> trouble with postgresql development", but that doesn't mean we should
> act as if this style of development doesn't exist.

Ah.  I see what you mean.   Sorry for the misunderstanding.

The thing is, from the perspective of *current* Postgres users, 7.4 has 
several "killer" features, some of which have been ready for 3 months.  In 
fact, I just finished sending an e-mail to a client advising them to try 7.4 
as soon as it is tested, becuase of hashaggs.

So looked at from that perspective, our mistake was to try to cram too many 
features into 7.4 ... more than could possibly get done in 6-8 months.   
What's happening now is that the core group has decided, OK, we don't have 
5-6 of the features we wanted to have, but we do have 10 other features, so 
maybe it's time to release.

I'm not sure you're correct in the behaviour of the majoirty of OSS projects.   
Certainly if the Mozilla or OpenOffice.org projects are attaching specific 
release numbers to specific features, I haven't seen it.  Linux does that, I 
guess, but that does result in a 2-year span between major releases -- and 
results in a lot of major features being included in "incremental" releases. 
But I think most OSS projects just release when they think they have enough 
tested features to justify a major release -- regardless of what those 
features are.

Anybody here on other projects want to weigh in?

Me, I'd be in favor of releasing more frequently ... I felt that we waited too 
long for 7.4.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

Fri, 20 Jun 2003 09:34:58 -0700
Josh Berkus <josh@agliodbs.com>
Re: Two weeks to feature freeze
Josh Berkus <josh@agliodbs.com> writes:
> So looked at from that perspective, our mistake was to try to cram too many 
> features into 7.4 ... more than could possibly get done in 6-8 months.   

It's more that we thought that all these features would get done in
about the same timeframe, and (not too surprisingly) some got done and
some didn't.

> Me, I'd be in favor of releasing more frequently ... I felt that we
> waited too long for 7.4.

Yeah, this is why I'm not in favor of slipping more.

Time was that we had a major release every 3 or 4 months.  As the project
matures I think it's appropriate for the cycle to get slower: a lot of
low-hanging fruit is gone, so we have larger jobs to tackle, plus users
are using PG for larger databases and don't want to face major-version
changes too often.  But I don't want it to get to be a year on average
between releases, at least not yet.  8 or 9 months seems reasonable, and
by that standard we're overdue.

			regards, tom lane

Fri, 20 Jun 2003 12:54:35 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Two weeks to feature freeze 
On Fri, 20 Jun 2003, Josh Berkus wrote:

> Ultimately, this is one of those "technical" vs. "marketing" questions
> ...  whether to release now with a bunch of back-end features that the
> current users want, or to release later and include the features that we
> said were going to be in 7.4.  And PostgreSQL is a technical project,
> not a marketing one.

Technical or Marketing, I think ppl are putting too much emphasis on
'visible features' and not enough on the 'not so visible' ones ...
improvements to both performance and footprint are massive changes, but
they are more difficult to 'market', then, say, adding schemas was ...


Sat, 21 Jun 2003 11:46:46 -0300 (ADT)
The Hermit Hacker <scrappy@postgresql.org>
Re: Two weeks to feature freeze 
On Fri, 20 Jun 2003, Tom Lane wrote:

> Time was that we had a major release every 3 or 4 months.  As the
> project matures I think it's appropriate for the cycle to get slower: a
> lot of low-hanging fruit is gone, so we have larger jobs to tackle, plus
> users are using PG for larger databases and don't want to face
> major-version changes too often.  But I don't want it to get to be a
> year on average between releases, at least not yet.  8 or 9 months seems
> reasonable, and by that standard we're overdue.

Note that with how we've been releasing 'minors' on v7.3.x semi-regularly,
slippage isn't *as* big an issue as it could have been ...

Sat, 21 Jun 2003 11:51:43 -0300 (ADT)
The Hermit Hacker <scrappy@postgresql.org>
Re: Two weeks to feature freeze 