Re: 8.5 release timetable, again - Mailing list pgsql-hackers

>>> Another solution would be to make major releases less frequent.
>> That's not a solution and you know it.
> 
> I do?

Ok, here's the reasons it's not a solution:

1) having a longer development cycle would frustrate many users who want
new features sooner, not later.  The current 1 year is a good compromise
between reliability and "release often".  A longer period would not be.

2) Lengthening the development period would make things less efficient.The amount of effort we need to test, document,
integrate,package,
 
etc., gets *greater* per patch when we have hundreds of patches.  So if
we *planned* an 18-month release, I expect that it would end up being a
24-month release.

3) If we deliberately lengthen the release cycle without doing anything
about why the post-CF portion takes so long, it will continue to get
longer, indefinitely.  Eventually, we're at 3.5 year releases and our
users abandoning Postgres for another database who can actually get a
release out.

4) It does nothing to address the *contributor* complaint that the
non-development part of our dev cycle is too long and keeps getting
longer.  A longer release cycle would make that worse.

If we could concievably do a release every 4 months, I believe that it
would be easy to keep the non-development portion of our cycle down to
30% or less.  We can't, so we need to look at ways to speed up the work
we're already doing.

> I have no idea how you know so much about me, but don't realize I was
> saying that we should extend the release cycle so we don't release as
> often, "make major releases less frequent" (every 12-14 months).  This
> has nothing to do with how we process the releases, parallel or not.

OK, to restate: making the cycle longer will not help the
development-to-integration&testing ratio.  It will make it worse.

> As I have said in the past, we are nearing feature-completeness (in a
> way), so having perhaps an 18-month release cycle is an idea.  That
> would give more time for development compared to beta, etc.

Per the above, it would not.  It would make things worse.  This has been
true at every other OSS project I've seen documented (disastrously so
with MySQL); there is no reason to believe that Postgres would be any
different.

I also do not see why you are so resistant to the idea of documenting a
tracking the post-CF steps so that we can get more people on them.

-- 
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com