Thread: 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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> 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@hub.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@hub.org Yahoo!: yscrappy ICQ: 7615664 > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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@hub.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@hub.org Yahoo!: yscrappy ICQ: 7615664 > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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@hub.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@Yahoo.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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.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@candle.pha.pa.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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.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@candle.pha.pa.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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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@candle.pha.pa.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@hub.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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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@candle.pha.pa.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@snappymail.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@hub.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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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@hub.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@hub.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@hub.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@jonathangardner.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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
"Marc G. Fournier" <scrappy@postgresql.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@hub.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@hub.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
> 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
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
-----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@jonathangardner.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@Yahoo.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 hinderthat? > 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@Yahoo.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/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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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@Yahoo.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@hub.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@hub.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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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@hub.org Yahoo!: yscrappy ICQ: 7615664
Christopher Browne wrote: > A long time ago, in a galaxy far, far away, Gaetano Mendola <mendola@bigfoot.com> wrote:>>>>I was thinking of somethingmuch simpler where Jan would create an>>>ARC patch against 7.4.X and have it either in /contrib for 7.4.X or>>>onour ftp servers, or on a web site. I could create a mechanism>>>so SELECT version() would display Jan's add-on.>>>>:-(>>>>Iwas asking to add the vacuum delayed patch to 7.4 months ago and>>the response was: why introduce instabilityto 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, aswell;> d) Tablespaces are way too immature to be included.>> Which eliminates all of the big, interesting reasons to upgradeto> 7.5.>> Or is ARC the only thing you regard as a misfeature? Interesting that> it was put into 7.5 _early_ inthe process, so that everyone that has> lately touched the betas would be getting bitten pretty heavily if it> was ladenwith 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@hub.org Yahoo!: yscrappy ICQ: 7615664
A long time ago, in a galaxy far, far away, Gaetano Mendola <mendola@bigfoot.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)
Tablespacesare 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