Re: Release cycle length

> > 0. As you say, make it known to the public. Have people test
> > their in-development applications using a beta.
>
> and how do you propose we do that? I think this is the hard part
> ... other then the first beta, I post a note out to -announce and
> -general that the beta's have been tag'd and bundled for download
> ... I know Sean does up a 'devel' port for FreeBSD, but I don't
> believe any of the RPM/deb maintainers do anything until the final
> release ...

Incidentally, the reason that I created the -devel port is because I
needed some of the features now and didn't want to wait for a release.
As things stand, I'm getting roughly 50-100 downloads a day of my
-devel snapshots, which leads me to believe that there is some
interest in having the release engineering team push features out the
door more quickly. My eye on the pgsql repo isn't perfect, but I know
I'm not the only one using it in production.

> > 5. If need be, have a release management team that manages 0-4.
>
> Core does that, but we just don't feel that being totally rigid is
> (or has ever been) a requirement ... but, if you can provide
> suggestions on points 0 and 3, we're all ears ...

You've got FreeBSD blood in you, you know that core(at)pgsql is the same
as trb(at)FreeBSD + core(at)FreeBSD + re(at)FreeBSD + qa(at)FreeBSD(dot) I think that
core(at)pgsql's big reason for wanting to have long release cycles is to
minimize the time that pgsql developers spend with their re@ and qa@
hats on. Truth be told, pgsql's code quality in the tree is so high
that a snapshot of HEAD is almost as good as a release... the
difference being the amount of attention spent on detail, docs,
finishing touches/polish. For the # of lines of code that go into
pgsql, it's nearly bug free over 95% of the time which means to me
with an releng hat on, that pgsql could stand to increase the rate of
releases so long as the developers can stomach doing the extra merges
from HEAD to the stable branch for feature additions or possibly
watching micro version numbers increment faster than they have
historically.

For all intents and purposes, pgsql's releases are stellar and the Pg
team makes every release very important to most everyone, where
important is defined as containing features useful for everyone: as
opposed to a re@ release often model where releases don't necessarily
useful features to a majority and just lead to upgrade thrashing which
is costly to organizations. Food for thought... nothing conclusive
here. -sc

--
Sean Chittenden