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

I am still going through my mailbox, trying to address all the open
patches so we can move toward beta. Of course, many of the patches I
kept need some adjustment to get applied (e.g. configuration file
location) so it is slow going.

However, we still have PITR unapplied, autovacuum unapplied, and nested
transactions don't have savepoint support, so we are still a while away
from beta. I think we should start thinking of beta as August 1 rather
than mid-July.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

> I am still going through my mailbox, trying to address all the open
> patches so we can move toward beta. Of course, many of the patches I
> kept need some adjustment to get applied (e.g. configuration file
> location) so it is slow going.
>
> However, we still have PITR unapplied, autovacuum unapplied, and nested
> transactions don't have savepoint support, so we are still a while away
> from beta. I think we should start thinking of beta as August 1 rather
> than mid-July.

Plus a bunch of other minor patches :)

Chris

On Sat, 10 Jul 2004, Bruce Momjian wrote:

> I am still going through my mailbox, trying to address all the open
> patches so we can move toward beta. Of course, many of the patches I
> kept need some adjustment to get applied (e.g. configuration file
> location) so it is slow going.
>
> However, we still have PITR unapplied, autovacuum unapplied, and nested
> transactions don't have savepoint support, so we are still a while away
> from beta. I think we should start thinking of beta as August 1 rather
> than mid-July.

And so we fall into the hole we dig for ourselves with each release, where
the beta period takes almost as long as the development period itself ...
originally, this was all supposed to be done for June 1st, but we pushed
it back to July 1st since ppl only needed "another month" ... then, July
1st, we did the feature freeze, but because so much was left to be
applied, we decided to leave bundling first beta until mid-July ...

If six extra weeks hasn't been enough, I have little faith that adding
'yet another 2 weeks' is going to be enough either ... leave them for 7.6
then ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

My point is that it isn't the patch submitters we are waiting on
anymore. It is the backlog of patches that need review/adjustment.

---------------------------------------------------------------------------

Marc G. Fournier wrote:
> On Sat, 10 Jul 2004, Bruce Momjian wrote:
>
> > I am still going through my mailbox, trying to address all the open
> > patches so we can move toward beta. Of course, many of the patches I
> > kept need some adjustment to get applied (e.g. configuration file
> > location) so it is slow going.
> >
> > However, we still have PITR unapplied, autovacuum unapplied, and nested
> > transactions don't have savepoint support, so we are still a while away
> > from beta. I think we should start thinking of beta as August 1 rather
> > than mid-July.
>
> And so we fall into the hole we dig for ourselves with each release, where
> the beta period takes almost as long as the development period itself ...
> originally, this was all supposed to be done for June 1st, but we pushed
> it back to July 1st since ppl only needed "another month" ... then, July
> 1st, we did the feature freeze, but because so much was left to be
> applied, we decided to leave bundling first beta until mid-July ...
>
> If six extra weeks hasn't been enough, I have little faith that adding
> 'yet another 2 weeks' is going to be enough either ... leave them for 7.6
> then ...
>
> ----
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Sat, 10 Jul 2004, Bruce Momjian wrote:

>
> My point is that it isn't the patch submitters we are waiting on
> anymore. It is the backlog of patches that need review/adjustment.

"Of course, many of the patches I kept need some adjustment to get applied
..." ... to me, that indicates that even after review, they will have to
go back to the submitter to be adjusted, and sent back, and reviewed, and
...

Get in what you feel comfortable adding over the next week, the rest can
wait until 7.6 ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

If you get full control of PostgreSQL, you can dictate what will happen.
Until then, I will follow the community consensus, which may or may not
match your opinion.

---------------------------------------------------------------------------

Marc G. Fournier wrote:
> On Sat, 10 Jul 2004, Bruce Momjian wrote:
>
> >
> > My point is that it isn't the patch submitters we are waiting on
> > anymore. It is the backlog of patches that need review/adjustment.
>
> "Of course, many of the patches I kept need some adjustment to get applied
> ..." ... to me, that indicates that even after review, they will have to
> go back to the submitter to be adjusted, and sent back, and reviewed, and
> ...
>
> Get in what you feel comfortable adding over the next week, the rest can
> wait until 7.6 ...
>
> ----
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:
> If you get full control of PostgreSQL, you can dictate what will happen.
> Until then, I will follow the community consensus, which may or may not
> match your opinion.

Um, let's take the time to get the features in, otherwise we'll be
waiting another year (roughly) to get PITR and others out to end users.

:)

Regards and best wishes,

Justin Clift

Justin Clift wrote:

> Bruce Momjian wrote:
>
>> If you get full control of PostgreSQL, you can dictate what will happen.
>> Until then, I will follow the community consensus, which may or may not
>> match your opinion.
>
>
> Um, let's take the time to get the features in, otherwise we'll be
> waiting another year (roughly) to get PITR and others out to end users.

We can't affort not having PITR or NT in 7.5; we announced it already
everywhere. But it's not a real problem if we need some more time to
release, we always tell "we don't release according to a release plan,
but if things are mature".

Regards,
Andreas

On 7/10/2004 11:02 PM, Bruce Momjian wrote:

> If you get full control of PostgreSQL, you can dictate what will happen.
> Until then, I will follow the community consensus, which may or may not
> match your opinion.

Marc isn't the only one who didn't like waiting for more features going
into 7.5 two months ago. I agree that it is too late now to push things
just out. But the mistake made wasn't ours.

What this repeated discussion about release plans and schedules (and we
have it every release) indicates to me is that we might miss something.
As you pointed out elsewhere, a 9-12 month development cycle just isn't
enough to get those big features done. But I think that stretching the
release cycle to two years and holding back all the smaller features as
well isn't a good idea either.

I think in the future we have to force all large features, those that
probably need more than 6 months of development time, to be properly
#ifdef'd. Then it wouldn't be that big of a deal to release more often.

Jan

>
> ---------------------------------------------------------------------------
>
> Marc G. Fournier wrote:
>> On Sat, 10 Jul 2004, Bruce Momjian wrote:
>>
>> >
>> > My point is that it isn't the patch submitters we are waiting on
>> > anymore. It is the backlog of patches that need review/adjustment.
>>
>> "Of course, many of the patches I kept need some adjustment to get applied
>> ..." ... to me, that indicates that even after review, they will have to
>> go back to the submitter to be adjusted, and sent back, and reviewed, and
>> ...
>>
>> Get in what you feel comfortable adding over the next week, the rest can
>> wait until 7.6 ...
>>
>> ----
>> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
>> Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
>>
>

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

Jan Wieck wrote:
> On 7/10/2004 11:02 PM, Bruce Momjian wrote:
>
> > If you get full control of PostgreSQL, you can dictate what will happen.
> > Until then, I will follow the community consensus, which may or may not
> > match your opinion.
>
> Marc isn't the only one who didn't like waiting for more features going
> into 7.5 two months ago. I agree that it is too late now to push things
> just out. But the mistake made wasn't ours.
>
> What this repeated discussion about release plans and schedules (and we
> have it every release) indicates to me is that we might miss something.
> As you pointed out elsewhere, a 9-12 month development cycle just isn't
> enough to get those big features done. But I think that stretching the
> release cycle to two years and holding back all the smaller features as
> well isn't a good idea either.
>
> I think in the future we have to force all large features, those that
> probably need more than 6 months of development time, to be properly
> #ifdef'd. Then it wouldn't be that big of a deal to release more often.

Alvaro started out with ifdef's but it got too confusing and we all
agreed to just go with a normal patch. He just hits too much code.
PITR could be done that way though.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Jan Wieck wrote:
>> I think in the future we have to force all large features, those that
>> probably need more than 6 months of development time, to be properly
>> #ifdef'd. Then it wouldn't be that big of a deal to release more often.

> Alvaro started out with ifdef's but it got too confusing and we all
> agreed to just go with a normal patch. He just hits too much code.

I think the same would be true of almost any really large feature ---
ifdefs all over the code base are just too much of a mess.

To be honest I think that "releasing more often" isn't necessarily an
appropriate goal for the project anymore. Five or six years ago we were
doing a major (initdb-forcing) release every three or four months, and
that was appropriate at the time, but the project has matured and our
user population has changed. Look at how many people are still using
7.2 or 7.3. One major release a year may be about right now, because
you can't get people to adopt new major revs faster than that anyway.

Of course this all ties into the pain of having to dump/reload large
databases, and maybe if we had working pg_upgrade the adoption rate
would be faster, but I'm not at all sure of that. We're playing in
a different league now. Big installations tend to want to do
significant amounts of compatibility testing before they roll out
a new database version.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Jan Wieck wrote:
> >> I think in the future we have to force all large features, those that
> >> probably need more than 6 months of development time, to be properly
> >> #ifdef'd. Then it wouldn't be that big of a deal to release more often.
>
> > Alvaro started out with ifdef's but it got too confusing and we all
> > agreed to just go with a normal patch. He just hits too much code.
>
> I think the same would be true of almost any really large feature ---
> ifdefs all over the code base are just too much of a mess.
>
> To be honest I think that "releasing more often" isn't necessarily an
> appropriate goal for the project anymore. Five or six years ago we were
> doing a major (initdb-forcing) release every three or four months, and
> that was appropriate at the time, but the project has matured and our
> user population has changed. Look at how many people are still using
> 7.2 or 7.3. One major release a year may be about right now, because
> you can't get people to adopt new major revs faster than that anyway.
>
> Of course this all ties into the pain of having to dump/reload large
> databases, and maybe if we had working pg_upgrade the adoption rate
> would be faster, but I'm not at all sure of that. We're playing in
> a different league now. Big installations tend to want to do
> significant amounts of compatibility testing before they roll out
> a new database version.

Totally agree.

I think the only downside to a longer release cycle is that features
developed would take longer to get out to the public. Perhaps we need
to start thinking of add-ons to existing releases such as an ARC or
vacuum-delay add-on to the 7.4.X release. The patch would potentially
have to be recreated for every minor release. I would also like to see
some psql message that shows the add-ons added to an official release.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> Of course this all ties into the pain of having to dump/reload large
>> databases, and maybe if we had working pg_upgrade the adoption rate
>> would be faster, but I'm not at all sure of that. We're playing in
>> a different league now. Big installations tend to want to do
>> significant amounts of compatibility testing before they roll out
>> a new database version.

> I think the only downside to a longer release cycle is that features
> developed would take longer to get out to the public. Perhaps we need
> to start thinking of add-ons to existing releases such as an ARC or
> vacuum-delay add-on to the 7.4.X release.

Mmm ... for people whose pain-point has to do with compatibility
testing, adding features in minor releases would turn them into major
releases, because they'd still have to wonder whether the new version
would break anything. I think our policy of "only bug fixes in stable
releases" is important to maintain, because it makes it easy for people
to upgrade within a stable release series.

Also, we do not really have the manpower to test multiple concurrently
developed versions ...

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >> Of course this all ties into the pain of having to dump/reload large
> >> databases, and maybe if we had working pg_upgrade the adoption rate
> >> would be faster, but I'm not at all sure of that. We're playing in
> >> a different league now. Big installations tend to want to do
> >> significant amounts of compatibility testing before they roll out
> >> a new database version.
>
> > I think the only downside to a longer release cycle is that features
> > developed would take longer to get out to the public. Perhaps we need
> > to start thinking of add-ons to existing releases such as an ARC or
> > vacuum-delay add-on to the 7.4.X release.
>
> Mmm ... for people whose pain-point has to do with compatibility
> testing, adding features in minor releases would turn them into major
> releases, because they'd still have to wonder whether the new version
> would break anything. I think our policy of "only bug fixes in stable
> releases" is important to maintain, because it makes it easy for people
> to upgrade within a stable release series.
>
> Also, we do not really have the manpower to test multiple concurrently
> developed versions ...

When I say add-ons, I am thinking of source code patches that are
avaiable as options to the standard subreleases. I agree we don't want
to change our current subrelease criteria.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Note that I'm all for a long (2 year? or even 'indefinite') development
cycle for a major release if we continue on with what has been happening
more often lately, where stuff is back patched to the last stable release
... 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 ...

The nice thing about doing something lke that is those small features
would get a degree of testing happening in a live environment ...

On Tue, 13 Jul 2004, Tom Lane wrote:

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> Jan Wieck wrote:
>>> I think in the future we have to force all large features, those that
>>> probably need more than 6 months of development time, to be properly
>>> #ifdef'd. Then it wouldn't be that big of a deal to release more often.
>
>> Alvaro started out with ifdef's but it got too confusing and we all
>> agreed to just go with a normal patch. He just hits too much code.
>
> I think the same would be true of almost any really large feature ---
> ifdefs all over the code base are just too much of a mess.
>
> To be honest I think that "releasing more often" isn't necessarily an
> appropriate goal for the project anymore. Five or six years ago we were
> doing a major (initdb-forcing) release every three or four months, and
> that was appropriate at the time, but the project has matured and our
> user population has changed. Look at how many people are still using
> 7.2 or 7.3. One major release a year may be about right now, because
> you can't get people to adopt new major revs faster than that anyway.
>
> Of course this all ties into the pain of having to dump/reload large
> databases, and maybe if we had working pg_upgrade the adoption rate
> would be faster, but I'm not at all sure of that. We're playing in
> a different league now. Big installations tend to want to do
> significant amounts of compatibility testing before they roll out
> a new database version.
>
> regards, tom lane
>

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:
>
> Note that I'm all for a long (2 year? or even 'indefinite') development
> cycle for a major release if we continue on with what has been happening
> more often lately, where stuff is back patched to the last stable release
> ... 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 ...
>
> The nice thing about doing something lke that is those small features
> would get a degree of testing happening in a live environment ...

Of course that last sentence is the downside too --- people don't want
to have to retest their setups after a minor release upgrade.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

On Tue, 2004-07-13 at 13:03 -0400, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Jan Wieck wrote:
> >> I think in the future we have to force all large features, those that
> >> probably need more than 6 months of development time, to be properly
> >> #ifdef'd. Then it wouldn't be that big of a deal to release more often.
>
> > Alvaro started out with ifdef's but it got too confusing and we all
> > agreed to just go with a normal patch. He just hits too much code.
>
> I think the same would be true of almost any really large feature ---
> ifdefs all over the code base are just too much of a mess.
>
> To be honest I think that "releasing more often" isn't necessarily an
> appropriate goal for the project anymore. Five or six years ago we were
> doing a major (initdb-forcing) release every three or four months, and
> that was appropriate at the time, but the project has matured and our
> user population has changed. Look at how many people are still using
> 7.2 or 7.3. One major release a year may be about right now, because
> you can't get people to adopt new major revs faster than that anyway.
>
> Of course this all ties into the pain of having to dump/reload large
> databases, and maybe if we had working pg_upgrade the adoption rate
> would be faster, but I'm not at all sure of that. We're playing in
> a different league now. Big installations tend to want to do
> significant amounts of compatibility testing before they roll out
> a new database version.
>
> regards, tom lane

It sounds like your only taking the point of view of people upgrading
previous installations. What about new installations? I'm sure there are
hundreds, if not thousands of new installations happening every week.
These people are going to grab the latest stable version without a
doubt.

I think releasing more often would result in features getting tested
much more. Then the "big installations" can see that a major feature has
been in two stable releases (even if the time period was only a year)
and feel much more comfortable in upgrading. Why would they have to
upgrade more often then necessary anyways? Assuming security exploits
are back ported of course.

--
Mike Benoit <ipso(at)snappymail(dot)ca>

On Tue, 13 Jul 2004, Bruce Momjian wrote:

>> The nice thing about doing something lke that is those small features
>> would get a degree of testing happening in a live environment ...
>
> Of course that last sentence is the downside too --- people don't want
> to have to retest their setups after a minor release upgrade.

Nobody would be required to upgrade to a new minor release either ...
nobody is *require* to upgrade to any release, for that matter ...

Hell, when we have a client that comes to us with a problem, we don't
recommend upgrading unless we find something in the RELEASE NOTES to
indicate something has been fixed related to their problem ... it isn't a
automatic "well, upgrade to the latest stable first, and then we can help
you" ...

God, we still have clients using 7.2 servers, cause they've had no reason
yet to upgrade to the latest ... "it works, why upgrade?" is generally the
opinion ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Bruce Momjian wrote:
>
> >> The nice thing about doing something lke that is those small features
> >> would get a degree of testing happening in a live environment ...
> >
> > Of course that last sentence is the downside too --- people don't want
> > to have to retest their setups after a minor release upgrade.
>
> Nobody would be required to upgrade to a new minor release either ...
> nobody is *require* to upgrade to any release, for that matter ...
>
> Hell, when we have a client that comes to us with a problem, we don't
> recommend upgrading unless we find something in the RELEASE NOTES to
> indicate something has been fixed related to their problem ... it isn't a
> automatic "well, upgrade to the latest stable first, and then we can help
> you" ...
>
> God, we still have clients using 7.2 servers, cause they've had no reason
> yet to upgrade to the latest ... "it works, why upgrade?" is generally the
> opinion ...

We have always recommended upgrading to the most recent minor release,
at least as a project policy for support. Also, the upgrade is only
stop/install/restart so it is quite easy to do, and folks like the fact
they don't have to test for new functionality.

One idea would be for us to release 7.5 and 7.5.0.1, and allow 7.5.1 to
have minor new features. That way, 7.5.0.[1-9] are no new features, and
7.5.[1-9] are minor improvements against 7.5.

Of course this does require more project management, and we already
don't have enough manpower.

I was thinking of something much simpler where Jan would create an ARC
patch against 7.4.X and have it either in /contrib for 7.4.X or on our
ftp servers, or on a web site. I could create a mechanism so SELECT
version() would display Jan's add-on.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Tue, 13 Jul 2004, Lamar Owen wrote:

> 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.

Except, we already have parallel branches, else we'd never have made a
7.4.x release ...

> 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...)

We have a CURRENT branch where all the 'innovations' are done (SMP
re-writes, etc) ... and a STABLE which is a release with stuff patched
down from CURRENT *if* applicable ... periodically, a RELEASE is made
along either branch, and, some day, what is currently CURRENT will be
re-tag'd as -STABLE, and then CURRENT will become a new branch ...

So, for instance, the way we number:

7.4.x would be -STABLE
HEAD would be -CURRENT

once 7.5 is released, it would surplant 7.4 as -STABLE, previous versions
would only ever see 'security related patches' and work towards 7.6
would be -CURRENT ...

Now, if we went with a 'long term dev cycle', then we might look at 7.x as
being -STABLE, while work towards 8.x would be considered -CURRENT ...

As a community, I don't think we should be 'supporting' anything older
then the last STABLE ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On Tue, 13 Jul 2004, Bruce Momjian wrote:

> I was thinking of something much simpler where Jan would create an ARC
> patch against 7.4.X and have it either in /contrib for 7.4.X or on our
> ftp servers, or on a web site. I could create a mechanism so SELECT
> version() would display Jan's add-on.

I think this would be a bad direction to take ... I can just see us
flooded with a bunch of 'the patch didn't apply to my source tree'
questions :(

It might work, I just have my doubts ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On Tue, 13 Jul 2004, Bruce Momjian wrote:

> We have always recommended upgrading to the most recent minor release,
> at least as a project policy for support. Also, the upgrade is only
> stop/install/restart so it is quite easy to do, and folks like the fact
> they don't have to test for new functionality.

Right, and this made sense when we were dealing with a release every 4
months or so ... now we're talking about one every year, or two ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On Tuesday 13 July 2004 08:52 am, Jan Wieck wrote:
>
> I think in the future we have to force all large features, those that
> probably need more than 6 months of development time, to be properly
> #ifdef'd. Then it wouldn't be that big of a deal to release more often.
>
>

Take my opinion with a grain of salt, as I'm young and don't have much
experience with large, super-stable C projects.

However, looking at how the Linux community handles it, I think we can
borrow a lot of concepts from them.

Let's seperate out into two different communities: Stable and Dev.

The stable folks only want patches when necessary. They don't want new
features - they don't use them. They don't want anything but security or
stability patches. They don't want to be forced to upgrade.

New major versions are moved into the stable community, but they don't
replace old versions. No one ever says "upgrade or else!" Each major
version is kept by interested parties and patched as needed. They never
die, but are abandoned.

The dev community wants to try out all kinds of things. They aren't running
production code, so they can risk losing data. They don't have to be so
sensitive about backwards compatibility and reliability and security.

In the dev community, there is the main branch with all the accepted
features. When people feel it is time for a new major version, they spend
all their effort stabilizing that main branch. When it is finally stable,
they create a new major version and hand it off to the stable community.

People keep their own versions of postgresql in the dev community. These
compete with each other. For instance, if Tom and others don't feel like a
feature should go into the main dev branch, that doesn't mean that Bruce
won't put it in his own version and encourage people to develop against
that. When Bruce can prove that it is a useful feature and it works and is
stable enough, he will work on getting it in the main dev branch.

I know this isn't the way things have been done. I know that one of the
arguments against proposals like this is that it seperates out our pool of
developers. Yes, it will do that. But it will also open up development to
more people and more experimentation. Maybe in the end, we will have a
stable and dev community that is larger than the entire community we have
now.

--
Jonathan Gardner
jgardner(at)jonathangardner(dot)net

Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Bruce Momjian wrote:
>
> > I was thinking of something much simpler where Jan would create an ARC
> > patch against 7.4.X and have it either in /contrib for 7.4.X or on our
> > ftp servers, or on a web site. I could create a mechanism so SELECT
> > version() would display Jan's add-on.
>
> I think this would be a bad direction to take ... I can just see us
> flooded with a bunch of 'the patch didn't apply to my source tree'
> questions :(
>
> It might work, I just have my doubts ...

I have my doubts too, of course. :-)

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Marc G. Fournier wrote:
> Nobody would be required to upgrade to a new minor release either ...
> nobody is *require* to upgrade to any release, for that matter ...

Most people don't have the time to investigate release notes, release
policy details, etc. When there are bug fix updates, you use them.
When there are feature updates, you use them for the next installation.
Anything in between, or more variations added to that, just cause
confusion. And frankly, for the examples thrown around that use this
kind of policy, I can't see those as being very successful. I don't
want to use a "stable" branch of a database system that still changes
for random reasons. And I don't want a "current" branch that takes
years to finalize. More frequent major releases, to the point that we
can stem it, lead to more people getting more features earlier, which
is good. Any of the other proposal just make things worse in my mind.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Bruce Momjian wrote:
>
> > We have always recommended upgrading to the most recent minor release,
> > at least as a project policy for support. Also, the upgrade is only
> > stop/install/restart so it is quite easy to do, and folks like the fact
> > they don't have to test for new functionality.
>
> Right, and this made sense when we were dealing with a release every 4
> months or so ... now we're talking about one every year, or two ...

I meant if they are on 7.4.X they should be on 7.4.3. I don't suggest
they have to upgrade 7.2.X to 7.4.X.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

"Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> On Tue, 13 Jul 2004, Lamar Owen wrote:
>> 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.

> Except, we already have parallel branches, else we'd never have made a
> 7.4.x release ...

The point though is that we expend only very minimal effort on
maintaining the stable branches. We only back-patch bug fixes, and 99%
of the time the patch is nearly verbatim the same change as we developed
to fix the same problem in HEAD. If the code involved has changed
enough that a significantly different fix would be required, most of the
time we simply don't fix the stable branch. And we spend very nearly
zero effort on QA for the stable branch --- there's certainly no
significant push to get people to beta-test minor releases.

If we did anything much in the way of back-porting features then the
level of investment in this would have to rise greatly. In fact, if the
proposal is to let people pick and choose which back-ported things they
install, then we are not talking about just one stable version but 2^N
stable versions for N options. We couldn't possibly test every
combination.

>> The BSD's release something like that, with CURRENT, TESTING, and STABLE,
>> right? (I'm not a big BSD user...)

Yeah, but they don't support mix-and-match feature sets. A back release
has only one current version.

We could certainly do something along that line if we had a few people
willing to be "gatekeepers". We'd have to work harder at making the
release generation process open and documented though. Right now there
are plenty of steps that only you, Bruce, or Lamar (respectively) know
how to do...

regards, tom lane

On Wed, 14 Jul 2004, Peter Eisentraut wrote:

> Marc G. Fournier wrote:
>> Nobody would be required to upgrade to a new minor release either ...
>> nobody is *require* to upgrade to any release, for that matter ...
>
> Most people don't have the time to investigate release notes, release
> policy details, etc. When there are bug fix updates, you use them.
> When there are feature updates, you use them for the next installation.
> Anything in between, or more variations added to that, just cause
> confusion. And frankly, for the examples thrown around that use this
> kind of policy, I can't see those as being very successful. I don't
> want to use a "stable" branch of a database system that still changes
> for random reasons. And I don't want a "current" branch that takes
> years to finalize. More frequent major releases, to the point that we
> can stem it, lead to more people getting more features earlier, which
> is good. Any of the other proposal just make things worse in my mind.

'k, note that I'm not arguing for more (or less) frequent releases ...
but, do you have any thoughts on how we can effectively continue with the
'frequent releases' while bringing in the large features like Nested
Xacts?

We could start looking at 'development branches' for stuff like this, that
could be merged up when ready for prime time, but would at least be
available in CVS for those wishing to play with them ... ?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On Tue, 13 Jul 2004, Tom Lane wrote:

> We could certainly do something along that line if we had a few people
> willing to be "gatekeepers". We'd have to work harder at making the
> release generation process open and documented though. Right now there
> are plenty of steps that only you, Bruce, or Lamar (respectively) know
> how to do...

I think we could do it if we restricted it to *just* one release back ...
but I do agree with Peter about ppls motivations for upgrading (bug fixes
vs new features) ... we'd have to have a 'two branch stable', one would be
only bug fixes, the other would be bug fixes+feature backpatch ... would
could get interesting trying to figure out release naming conventions :)

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On Tue, 2004-07-13 at 20:49, Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Tom Lane wrote:
>
> > We could certainly do something along that line if we had a few people
> > willing to be "gatekeepers". We'd have to work harder at making the
> > release generation process open and documented though. Right now there
> > are plenty of steps that only you, Bruce, or Lamar (respectively) know
> > how to do...
>
> I think we could do it if we restricted it to *just* one release back ...
> but I do agree with Peter about ppls motivations for upgrading (bug fixes
> vs new features) ... we'd have to have a 'two branch stable', one would be
> only bug fixes, the other would be bug fixes+feature backpatch ... would
> could get interesting trying to figure out release naming conventions :)

FreeBSD does do this. They tag the bug-fix only branches as being
SECURITY releases, since typically they only contain fixes for security
or reliability related issues.

The 5.2.1 release which followed 5.2.0 was an example of one of the few
releases the Security team has done. They usually just allow users to
use CVSUP to follow the branch.

> However, looking at how the Linux community handles it, I think we can
> borrow a lot of concepts from them.

I was thinking quite the opposite. The Linux community doesn't exactly
have a great track-record for their stable releases.

The thoughts behind the process might be good, but do we have examples
where it has worked out well? The 2.4 series seems to have been
particularly bad for new major issues in their stable releases.

> God, we still have clients using 7.2 servers, cause they've had no
> reason yet to upgrade to the latest ... "it works, why upgrade?" is
> generally the opinion ...

Because there's shocking failure-to-restart bugs in 7.2...and if you
upgrade to 7.4 you're forced to get new features as well.

Chris

> I was thinking of something much simpler where Jan would create an ARC
> patch against 7.4.X and have it either in /contrib for 7.4.X or on our
> ftp servers, or on a web site. I could create a mechanism so SELECT
> version() would display Jan's add-on.

I think you guys just need to learn to become comfortable with being
hard-nosed about this. Just Do Not Care about people who "want" ARC
right this second. Do you see them calling up Oracle and saying please
backport the new stuff from 11i-devel so we can use it now please?

You learn after a long while in the software industry that if left to
themselves the users will make _endless_ demands and they think that
they NEED everything NOW. Of course in reality, they don't NEED it NOW
- they can wait. And even if they did get it now, then it's buggy and
then they complain even louder. You cannot win. The arguments about
things "getting more testing" in production is nonsense - we are a major
database server - you cannot have users doing the testing for us!!!!

They have signed on to the PostgreSQL project on "our" terms of
development - if they want to sponsor someone to backport something for
their own situation, they can do so. Otherwise, they perhaps should
have not been using PostgreSQL for their particular app in the first place!

It's not worth thinking along the lines of "oh if only we could get this
feature out RIGHT NOW, we'd get more users and more people uprading and
convertign and better reviews and stuff - but that's a distraction.
There will ALWAYS be Just One More Feature that we need to be "really
great". Just don't worry about it.

Chris

Marc G. Fournier wrote:
<snip>
> 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 ...
<snip>

Hmmm... so we do things slightly differently than previously...

This upcoming version could be PG version 8.0,
We continue with bugfixes on 7.4.x,
That still leaves 7.5.x, 7.6.x (etc if needed), for releasing new
versions of PG without the "big features".

Kind of like an in-between thing, whilst waiting for the major features
in the major releases?

That would mean we'd have:

Version 8.0 as our next main release,
Version 9.0 being the version after that with the next "big features" in it.
Version 8.x being version 8 plus smaller features, prior to 9.0
Version 8.x.x being version 8.x plus bug fixes.

Sounds like it could get hairy if we're not careful, but I reckon the PG
Community is mature enough to make the right calls where needed.

:)

Regards and best wishes,

Justin Clift

> The thoughts behind the process might be good, but do we have examples
> where it has worked out well? The 2.4 series seems to have been
> particularly bad for new major issues in their stable releases.

PHP's the same. Absolutely dreadful. They put all sorts of new
features mixed in with security and bug fixes in their minor releases.
The NUMBER OF TIMES I've upgraded PHP to fix a bug and they've
introduced a new global function that conflicts with one of my user one
and worse...

Chris

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 13 July 2004 7:33 pm, Christopher Kings-Lynne wrote:
>
> PHP's the same. Absolutely dreadful. They put all sorts of new
> features mixed in with security and bug fixes in their minor releases.
> The NUMBER OF TIMES I've upgraded PHP to fix a bug and they've
> introduced a new global function that conflicts with one of my user one
> and worse...
>

I was arguing quite the opposite. New features wouldn't be introduced into
code that is in the stable community. Only bug fixes and security patches
would be introduced to the stable community, and very carefully.

- --
Jonathan Gardner
jgardner(at)jonathangardner(dot)net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFA9J89qp6r/MVGlwwRAh6CAKDCJhuomf8hWbHMHGqrYfCGi5QzxQCfT4Hs
feHVoYbFW0tq6BwJtFxy+EE=
=BmHk
-----END PGP SIGNATURE-----

On 7/13/2004 10:23 PM, Christopher Kings-Lynne wrote:

>> I was thinking of something much simpler where Jan would create an ARC
>> patch against 7.4.X and have it either in /contrib for 7.4.X or on our
>> ftp servers, or on a web site. I could create a mechanism so SELECT
>> version() would display Jan's add-on.
>
> I think you guys just need to learn to become comfortable with being
> hard-nosed about this. Just Do Not Care about people who "want" ARC
> right this second. Do you see them calling up Oracle and saying please
> backport the new stuff from 11i-devel so we can use it now please?

Hmmm ... I wonder what you think who those people are who "want" ARC
right this second, and who "you guys" are on the other hand.

To fill you in a little, I am the PostgreSQL CORE team member Jan Wieck,
who burned Afilias payroll hours to implement the ARC buffer replacement
strategy. The feature has been completed and fully contributed under the
BSD license way ahead of any possible release schedule. I have had
several requests for backports, but consider the feature too delicate to
make such patch available. Don't worry, it's not one of my goals to get
this into any release, the reason I am personally touched by this is not
because it affects my checking account in any way.

What touches me here is the fact that the PostgreSQL Open Source Project
under the BSD license seems starting to care a lot more about some press
releases and silly news splashes, than to care about real features
contributed under the terms and conditions of the BSD license by serious
members of the Open Source Community. Which part of the storage manager,
that Futjitsu uses so that their customers don't need ARC, the
background writer or vacuum at all, do you think will be contributed any
time soon?

Don't get me wrong here, I don't have a problem with someone making
money out of my 8+ years of contributions to this project. But I do have
a problem with those efforts getting in my way of contributing.

Come again about hard-nosing, please.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

> To fill you in a little, I am the PostgreSQL CORE team member Jan Wieck,
> who burned Afilias payroll hours to implement the ARC buffer replacement
> strategy. The feature has been completed and fully contributed under the
> BSD license way ahead of any possible release schedule. I have had
> several requests for backports, but consider the feature too delicate to
> make such patch available. Don't worry, it's not one of my goals to get
> this into any release, the reason I am personally touched by this is not
> because it affects my checking account in any way.

Yes, but it has been committed, it will be released - the only thing is
that people will have to wait a few more months for it. My point was
exactly what you are saying. It's not worth backporting it because it
is delicate, and it's not worth rushing to meet the demands of a vocal
number of users if it will cost too much time in terms of developer and
release engineering hours.

What I was saying is that we don't need to release stuff right now when
people demand it, if it is really inconvenient for us and we don't have
the manpower.

> What touches me here is the fact that the PostgreSQL Open Source Project
> under the BSD license seems starting to care a lot more about some press
> releases and silly news splashes, than to care about real features
> contributed under the terms and conditions of the BSD license by serious
> members of the Open Source Community.

There's a place for both. I do development for PostgreSQL because it's
fun - however it would make me sad to see PostgreSQL as a whole wither
and die because we get no press, no new users, no good reviews and
everyone just uses MySQL...

Also, it's a good way for people who cannot code to contribute to the
project.

> Which part of the storage manager,
> that Futjitsu uses so that their customers don't need ARC, the
> background writer or vacuum at all, do you think will be contributed any
> time soon?

Well, that's not possible to answer. However, they have already paid
for tablespaces and nested transactions, so who am I to begrudge them
their storage manager?

> Don't get me wrong here, I don't have a problem with someone making
> money out of my 8+ years of contributions to this project. But I do have
> a problem with those efforts getting in my way of contributing.

I'm not quite sure how you've been inhibited from contributing? You've
done a bunch of stuff for 7.5, that is committed and will be in release.
How will press releases and news splashes hinder that?

> Come again about hard-nosing, please.

I'm actually not sure you are disagreeing with me, Jan...

Chris

On 7/14/2004 5:00 AM, Christopher Kings-Lynne wrote:

> Yes, but it has been committed, it will be released - the only thing is
> that people will have to wait a few more months for it. My point was

Just a few more months? That is exactly what I was asking for, put some
of the stuff into 7.6 so it will be released in a few more months
instead of holding back the release now.

> Well, that's not possible to answer. However, they have already paid
> for tablespaces and nested transactions, so who am I to begrudge them
> their storage manager?

Afilias has already payed for as well. Are they paying in some strange
kind of different dollars or what?

>> Don't get me wrong here, I don't have a problem with someone making
>> money out of my 8+ years of contributions to this project. But I do have
>> a problem with those efforts getting in my way of contributing.
>
> I'm not quite sure how you've been inhibited from contributing? You've
> done a bunch of stuff for 7.5, that is committed and will be in release.
> How will press releases and news splashes hinder that?

There is again this "will be released". Great, but what I don't get is
why the stuff that wasn't ready at the original release schedule
qualifies in your mind easily to push back, when my stuff that was ready
is so unimportant that it can simply be jiggled around for a couple of
months. Are nested transactions that more or an "everyone needs" feature
than the benefits resulting from an improved cache algorithm?

>
>> Come again about hard-nosing, please.
>
> I'm actually not sure you are disagreeing with me, Jan...

Probably not. And as usual, I don't mean you in person, even if I
"would" call you by name just to make my point ;-)

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

Jan Wieck wrote:
> On 7/14/2004 5:00 AM, Christopher Kings-Lynne wrote:
>
>> Yes, but it has been committed, it will be released - the only thing
>> is that people will have to wait a few more months for it. My point was
>
>
> Just a few more months? That is exactly what I was asking for, put some
> of the stuff into 7.6 so it will be released in a few more months
> instead of holding back the release now.

If we really released major versions every 4-6 months, what about the
last stable version? If only the current and the last version are
supported, this would mean that security/bugfixes are available only to
versions no older than 8 months or so, or said the other way around if I
need a bug fixed stable version I'll have to upgrade to the next major
version after quite a short time. We'd have to support 2-3 versions
older than the current release to cover one year major version
stability, which appears not viable for the community.

Seems we're stuck in the present way, being probably the best that can
be made with limited resources.

Regards,
Andreas

Jan Wieck wrote:
> On 7/13/2004 10:23 PM, Christopher Kings-Lynne wrote:
>
> >> I was thinking of something much simpler where Jan would create an ARC
> >> patch against 7.4.X and have it either in /contrib for 7.4.X or on our
> >> ftp servers, or on a web site. I could create a mechanism so SELECT
> >> version() would display Jan's add-on.
> >
> > I think you guys just need to learn to become comfortable with being
> > hard-nosed about this. Just Do Not Care about people who "want" ARC
> > right this second. Do you see them calling up Oracle and saying please
> > backport the new stuff from 11i-devel so we can use it now please?
>
> Hmmm ... I wonder what you think who those people are who "want" ARC
> right this second, and who "you guys" are on the other hand.
>
> To fill you in a little, I am the PostgreSQL CORE team member Jan Wieck,
> who burned Afilias payroll hours to implement the ARC buffer replacement
> strategy. The feature has been completed and fully contributed under the
> BSD license way ahead of any possible release schedule. I have had
> several requests for backports, but consider the feature too delicate to
> make such patch available. Don't worry, it's not one of my goals to get
> this into any release, the reason I am personally touched by this is not
> because it affects my checking account in any way.
>
> What touches me here is the fact that the PostgreSQL Open Source Project
> under the BSD license seems starting to care a lot more about some press
> releases and silly news splashes, than to care about real features
> contributed under the terms and conditions of the BSD license by serious
> members of the Open Source Community. Which part of the storage manager,
> that Futjitsu uses so that their customers don't need ARC, the
> background writer or vacuum at all, do you think will be contributed any
> time soon?
>
> Don't get me wrong here, I don't have a problem with someone making
> money out of my 8+ years of contributions to this project. But I do have
> a problem with those efforts getting in my way of contributing.

What are you talking about? Are you suggesting Fujitsu's features are
getting more attendtion than ARC for some political reason? You think
nested transactions and tablespaces are just press release features?
All those features are being developed by the community under community
direction and based on community feedback/needs. How is that different
from Afilias funding ARC?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Jan Wieck wrote:
> On 7/14/2004 5:00 AM, Christopher Kings-Lynne wrote:
>
> > Yes, but it has been committed, it will be released - the only thing is
> > that people will have to wait a few more months for it. My point was
>
> Just a few more months? That is exactly what I was asking for, put some
> of the stuff into 7.6 so it will be released in a few more months
> instead of holding back the release now.
>
> > Well, that's not possible to answer. However, they have already paid
> > for tablespaces and nested transactions, so who am I to begrudge them
> > their storage manager?
>
> Afilias has already payed for as well. Are they paying in some strange
> kind of different dollars or what?
>
> >> Don't get me wrong here, I don't have a problem with someone making
> >> money out of my 8+ years of contributions to this project. But I do have
> >> a problem with those efforts getting in my way of contributing.
> >
> > I'm not quite sure how you've been inhibited from contributing? You've
> > done a bunch of stuff for 7.5, that is committed and will be in release.
> > How will press releases and news splashes hinder that?
>
> There is again this "will be released". Great, but what I don't get is
> why the stuff that wasn't ready at the original release schedule
> qualifies in your mind easily to push back, when my stuff that was ready
> is so unimportant that it can simply be jiggled around for a couple of
> months. Are nested transactions that more or an "everyone needs" feature
> than the benefits resulting from an improved cache algorithm?

The community decides when to stop development. Neither Afilias nor any
other company has that control. If you want the development cycle cut
shorter, make your case to the community --- if you win, great, if not,
don't gripe about it.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On 7/14/2004 1:13 PM, Bruce Momjian wrote:

> What are you talking about? Are you suggesting Fujitsu's features are
> getting more attendtion than ARC for some political reason? You think
> nested transactions and tablespaces are just press release features?
> All those features are being developed by the community under community
> direction and based on community feedback/needs. How is that different
> from Afilias funding ARC?
>

I was getting a little upset about the suggestion of being "hard-nosed"
against the people who want ARC now. Yes, I wanted those features out
earlier and this was not because of Afilias or dictated by Afilias, but
because there is demand for it from the community.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

On Wed, 14 Jul 2004, Bruce Momjian wrote:

> What are you talking about? Are you suggesting Fujitsu's features are
> getting more attendtion than ARC for some political reason? You think
> nested transactions and tablespaces are just press release features?
> All those features are being developed by the community under community
> direction and based on community feedback/needs. How is that different
> from Afilias funding ARC?

No, the beef that Jan has, and that I also have, is that we put off the
release that was schedualed for June 1st in order to get Nested Xacts into
the tree ... hindsight being 20-20, we shouldn't have done that, but
should have delayed Nested Xacts for 7.6 ... there *were* enough features
in the tree to warrant a release, and features that ppl needed / wanted.

Do I believe there were political motivations for postponing the feature
freeze? Personally ... no. And I don't believe that the Press Release
(and a nice one at that) can really be counted as motivation for the
postponement, since the PR was done *after* we decided to push things back
a month ...

I do believe that there was some pressure from Futjitsu involved, in
postponing it, since they'd rather see it in sooner then later ... *but*
... I don't really believe that the pressure is any different then there
quite possibly could have been had, say, Jan been "almost finished" ARC
and Affilias wanted to see that sooner rather then later ... we all want
to see the feature we've either been working on, or funded, released as
soon as possible ...

The big problem that I see with how this feature freeze/beta/release has
gone down is that we have *alot* of big items that are/were being worked
on (ARC, BGWriter, auto_vacuum, PITR, Nested Xacts), and only so much man
power at the reviewer stage ... we *should* have frozen it all on June
1st, got the ready features out the door and released, and then
concentrated on getting the "almost ready, but not quite" features into
the next release as quickly as possible ...

Hindsight is 20-20 ... maybe next time we'll learn from it?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On Wed, 14 Jul 2004, Bruce Momjian wrote:

> The community decides when to stop development. Neither Afilias nor any
> other company has that control. If you want the development cycle cut
> shorter, make your case to the community --- if you win, great, if not,
> don't gripe about it.

Core decides when to stop development ... that is what cores role is ...
to *steer* the development of the code ... the community didn't decide to
extend the dev cycle this time, any more then it has in the past ... core
decided to ... period. end of story.

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:
> The big problem that I see with how this feature freeze/beta/release has
> gone down is that we have *alot* of big items that are/were being worked
> on (ARC, BGWriter, auto_vacuum, PITR, Nested Xacts), and only so much man
> power at the reviewer stage ... we *should* have frozen it all on June
> 1st, got the ready features out the door and released, and then
> concentrated on getting the "almost ready, but not quite" features into
> the next release as quickly as possible ...
>
> Hindsight is 20-20 ... maybe next time we'll learn from it?

True, 20-20. One thing is that you can't schedule assuming full
knowledge of the future, of course. For example, on May 1, I thought by
June 1 PITR and NT would be done, and that Win32 and tablespaces
wouldn't. What actually happened is that tablespaces made the deadline
(with June adjustments), NT is in but needs more work, and Win32 is
better off now than I thought it would be. And we don't know if PITR is
ready or not because we haven't studied it enough.

One problem with pushing 7.5 out June 1 and then coming back to these
features is losing momentum. Sure, ideally we could hit them all in
7.6, but realistically it is a lot harder to get things moving once you
stop. Look at the PITR patch we had for 7.3 (?) and are only now
getting it into the tree.

I am not saying we did things right or wrong --- just pointing out the
momentum issue.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Marc G. Fournier wrote:
> On Wed, 14 Jul 2004, Bruce Momjian wrote:
>
> > The community decides when to stop development. Neither Afilias nor any
> > other company has that control. If you want the development cycle cut
> > shorter, make your case to the community --- if you win, great, if not,
> > don't gripe about it.
>
> Core decides when to stop development ... that is what cores role is ...
> to *steer* the development of the code ... the community didn't decide to
> extend the dev cycle this time, any more then it has in the past ... core
> decided to ... period. end of story.
>

Not for me. I think core picks specific dates for release because it is
too hard to get concensus quickly on dates, but the community is
certainly involved in the setting of development cycles.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Tue, 2004-07-13 at 23:03, Marc G. Fournier wrote:

> As a community, I don't think we should be 'supporting' anything older
> then the last STABLE ...
>

I agree, but that message isn't clearly stated anywhere. The lists are
full of people running very old releases - and everybody keeps having to
ask "what release are you running" and the answer is always shocking.

Can we set up different lists for the various major versions, so people
can see where to go for different types of support?

Rather than General, have General7.4 and General7.3...making everybody's
first question "what is my release? where should I post this question?"
- 95% of people are newbies, whatever the list/project.

That will also make it clear that on-list support is available for older
releases, but they really should be thinking about upgrade. And
different people can choose whether to hang out at the bleeding edge, or
legacy support.

We could also have different hints and tips by list then. One of the
gems (hint 9, I think) is changing in r7.5, so we must either mis-advise
people who use the new release or fail to advise those using an older
release. The down-rev lists could contain advice about upgrading...

Best Regards, Simon Riggs

Bruce Momjian wrote:

> I was thinking of something much simpler where Jan would create an ARC
> patch against 7.4.X and have it either in /contrib for 7.4.X or on our
> ftp servers, or on a web site. I could create a mechanism so SELECT
> version() would display Jan's add-on.

:-(

I was asking to add the vacuum delayed patch to 7.4 months ago and the response
was: why introduce instability to a stable release ?
I hope the global consensus is a no way to procede also for ARC.

It's true the version 7.5 ( or 8.0 ) will be really a great release but
IMHO introduce in one shot:

1) PITR
2) Nested Transaction
3) WIN32 porting
4) ARC
5) Table Space
6) I'm sure I'm forgetting something

was really too much.

I hope that all will be fine.

Regards
Gaetano Mendola

On Wed, 2004-07-14 at 21:02, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > The big problem that I see with how this feature freeze/beta/release has
> > gone down is that we have *alot* of big items that are/were being worked
> > on (ARC, BGWriter, auto_vacuum, PITR, Nested Xacts), and only so much man
> > power at the reviewer stage ... we *should* have frozen it all on June
> > 1st, got the ready features out the door and released, and then
> > concentrated on getting the "almost ready, but not quite" features into
> > the next release as quickly as possible ...
> >
> > Hindsight is 20-20 ... maybe next time we'll learn from it?
>
> True, 20-20. One thing is that you can't schedule assuming full
> knowledge of the future, of course. For example, on May 1, I thought by
> June 1 PITR and NT would be done, and that Win32 and tablespaces
> wouldn't. What actually happened is that tablespaces made the deadline
> (with June adjustments), NT is in but needs more work, and Win32 is
> better off now than I thought it would be. And we don't know if PITR is
> ready or not because we haven't studied it enough.
>

I see a couple of issues:
- new releases of PostgreSQL require a full initdb. There is little
upgrade support as there is with other products. (Not complaining..)
- commercial products release around every 18 months...customers do NOT
want this to be any quicker...more disruptive upgrades, plus marketing
takes time to organise. I have customers that upgrade regularly every 3+
years (!), and take longer term strategy into consideration.
- commercial issues often cause products to be delayed....MS is said to
be late delivering Yukon....marketing-led companies often delay waiting
for the right feature set....saled-led companies never do. Delivering
early as Oracle often does mean that the received wisdom is never
upgrade to a x.0 version, always wait for the x.1 minor version where
all the features actually work as advertised.

Deadlines are great, but advertise them ahead of time, then stick to
them. Every other project I see has a big page saying "how to
contribute" and then details of deadlines etc..

We can have a major feature deadline, then a minor feature deadline. I
particularly liked the idea of 1 July as the major feature deadline,
then 14 July as major-feature-tweak deadline. That funnels things better
to cater for the manpower available.

Best Regards, Simon Riggs

> We can have a major feature deadline, then a minor feature deadline. I
> particularly liked the idea of 1 July as the major feature deadline,
> then 14 July as major-feature-tweak deadline. That funnels things better
> to cater for the manpower available.

That being said, your PITR patch still hasn't been comitted and it's
well past 1st July. If I had to drop something from 7.5 right now to
make a release, then it would have to be PITR!

Chris

Christopher Kings-Lynne wrote:
> > We can have a major feature deadline, then a minor feature deadline. I
> > particularly liked the idea of 1 July as the major feature deadline,
> > then 14 July as major-feature-tweak deadline. That funnels things better
> > to cater for the manpower available.
>
> That being said, your PITR patch still hasn't been comitted and it's
> well past 1st July. If I had to drop something from 7.5 right now to
> make a release, then it would have to be PITR!

Well, the problem is that Simon isn't the reason the patch hasn't been
applied. The reason is that we have had other priorities in reviewing
patches so it doesn't seem fair to single out that feature for
exclusion.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Thu, 15 Jul 2004, Christopher Kings-Lynne wrote:

>> We can have a major feature deadline, then a minor feature deadline. I
>> particularly liked the idea of 1 July as the major feature deadline,
>> then 14 July as major-feature-tweak deadline. That funnels things better
>> to cater for the manpower available.
>
> That being said, your PITR patch still hasn't been comitted and it's well
> past 1st July. If I had to drop something from 7.5 right now to make a
> release, then it would have to be PITR!

As Bruce would put it "that would be unfair to Simon", since it isn't his
fault that the patch hasn't been reviewed for commit yet ... if, once
reviewed, it is found to need work, then it should be put off until 7.6
... I'm in Josh's camp on this one, in that Nested Xacts should probably
be pulled since it still needs work :(

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

A long time ago, in a galaxy far, far away, Gaetano Mendola <mendola(at)bigfoot(dot)com> wrote:
>> I was thinking of something much simpler where Jan would create an
>> ARC patch against 7.4.X and have it either in /contrib for 7.4.X or
>> on our ftp servers, or on a web site. I could create a mechanism
>> so SELECT version() would display Jan's add-on.
>
> :-(
>
> I was asking to add the vacuum delayed patch to 7.4 months ago and
> the response was: why introduce instability to a stable release ? I
> hope the global consensus is a no way to procede also for ARC.

If, as you suggest, ARC is too immature to go in, then I presume that
would also imply that "global consensus" should also be that:

a) PITR is much too immature to put in;
b) Win32 is way too immature to put in;
c) NT is way too immature, as well;
d) Tablespaces are way too immature to be included.

Which eliminates all of the big, interesting reasons to upgrade to
7.5.

Or is ARC the only thing you regard as a misfeature? Interesting that
it was put into 7.5 _early_ in the process, so that everyone that has
lately touched the betas would be getting bitten pretty heavily if it
was laden with bugs...
--
output = reverse("gro.mca" "@" "enworbbc")
http://www.ntlug.org/~cbbrowne/emacs.html
"There is something in the lecture course which may not have been
visible so far, which is reality ..." -- Arthur Norman

Christopher Browne wrote:

> A long time ago, in a galaxy far, far away, Gaetano Mendola <mendola(at)bigfoot(dot)com> wrote:
>
>>>I was thinking of something much simpler where Jan would create an
>>>ARC patch against 7.4.X and have it either in /contrib for 7.4.X or
>>>on our ftp servers, or on a web site. I could create a mechanism
>>>so SELECT version() would display Jan's add-on.
>>
>>:-(
>>
>>I was asking to add the vacuum delayed patch to 7.4 months ago and
>>the response was: why introduce instability to a stable release ? I
>>hope the global consensus is a no way to procede also for ARC.
>
>
> If, as you suggest, ARC is too immature to go in, then I presume that
> would also imply that "global consensus" should also be that:
>
> a) PITR is much too immature to put in;
> b) Win32 is way too immature to put in;
> c) NT is way too immature, as well;
> d) Tablespaces are way too immature to be included.
>
> Which eliminates all of the big, interesting reasons to upgrade to
> 7.5.
>
> Or is ARC the only thing you regard as a misfeature? Interesting that
> it was put into 7.5 _early_ in the process, so that everyone that has
> lately touched the betas would be getting bitten pretty heavily if it
> was laden with bugs...

No no, please don't mistake me. I wrote that shall be a no way to back patch
ARC in the 7.4 version, starting from consideration that the delayed vacuum
was considered too dangerous...

My humble opinion is that have all that new funcionts in one shot with the same
ammount of beta period for other release is too dangerous. From my side the
only think that I can do with a beta is just run our regression tests ( almost
2000 tests ) for our installation, but for sure I can not use it extensively.
We could ( may be is a crazy idea )release the

7.5 with ARC + BW + new list implemetation
7.6 with 7.5 + PITR
7.7 with 7.6 + NT
7.8 with 7.7 + Win32
7.9 with 7.8 + Table Space

with 2 months between a release and the other with a one month of beta for
each release; this in order to reach the version 8.0 rock stable; and possibly
without need to initdb between these releases.

Is it too insane ? :-)

I'm sorry to see Postgresql releases driven by advertisment instead by good sense
( as it was till today ).

Regards
Gaetano Mendola

On Thu, 15 Jul 2004, Gaetano Mendola wrote:

> I'm sorry to see Postgresql releases driven by advertisment instead by
> good sense ( as it was till today ).

The releases are not being driving by advertisement ... note that the
decisions for including the features you list above was made before the
press release was made ... these were features that were pretty much
plan'd since the development cycle for 7.5 began way back when ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664