Re: Release planning (was: Re: Status report)

On Tuesday 13 July 2004 17:12, Marc G. Fournier wrote:
> ... there is alot of stuff that doesn't require a reload of the database
> (or initdb) that could very easily be backpatched ...

> As Jan points out, its the 'small features that are done' that we've been
> griping about having to wait for, not the big ones which we know aren't
> done ...

Split the feature out into either a patch or a module and put it in contrib
until the next major version. Let contrib hold the smaller,
non-initdb-forcing patches and such until the next major version rolls them
into the mainline. Or even a patches tree parallel to contrib. Either way,
the patch or module or whatever wouldn't be in the mainline unless the user
needed it.

Or maybe we need to rethink what a major version is. But even minor things
can force an initdb, although we're better than we have been about this.

But Tom's assertion is true. We have enough trouble getting patches rolled
out; adding parallel branches is just begging for trouble, due to our
relatively small resource size. Although, we probably have enough developers
at this point to make it happen.

Bruce I would want to be the patchmeister for the stable branch. Someone else
(with Bruce's oversight, or Tom's, or whoever) could do the patchmunging and
review for the development tree. But I want a stable hand on patches that go
into the stable tree.

The BSD's release something like that, with CURRENT, TESTING, and STABLE,
right? (I'm not a big BSD user...) The Linux kernel has parallel
development, and a gatekeeper for each stable release (2.0.x, 2.2.x, 2.4.x,
and now 2.6.x). A 2.0.x kernel release happened not too long ago, in fact.
We probably could have enough volunteers to do something like that.
Gatekeeping a stable release would not be as complex as developing the new
release, but, again, I would want an experienced hand on the last stable
release where the temptation of backporting 'features' is great. I think a
gatekeeper for 7.2.x, for example, would have very little to do except once
in a great while if and when a serious bug is found. At that point, that
gatekeeper can make a release (the current process is too tied up in people,
IMO, and that includes the RPM mechanism (which I have every right to
criticize!)).
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu