Re: [HACKERS] Release planning
A long time ago, in a galaxy far, far away, Gaetano Mendola [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Release planning
Christopher Browne wrote: A long time ago, in a galaxy far, far away, Gaetano Mendola [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Release planning
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Release planning
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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Release planning
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. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Release planning
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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Release planning
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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Release planning (was: Re: Status report)
Jan, 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. I don't get this. At what point did you seriously expect that 7.5 would be out less than a year after 7.4? The only circumstance I can recall discussing on -Core under which PG7.5 would be released early was if Win32 was ready and debugged by March. Otherwise, I was certainly expecting that things would go more or less as they did last year (though hopefully with more bugs caught during beta) and nothing we discussed here or on -Core led me to think otherwise. I do agree that the fact that, for example, NTs have gotten press coverage is *no* reason to decide whether to keep them for 7.5 or push them to 7.6. Press coverage exists to enhance the image of PostgreSQL and not to influence development. Nor is the fact that FJ sponsored the feature in question significant; if they want it ASAP, they can afford to backport. No, the questions which are important are the below. And keep in mind that the *only* patch we're talking about holding back is NTs; so far, nobody has raised any issues with PITR or Tablespaces that would prevent them from being part of 7.5.0. 1) How long is it going to take to resolve the remaining issues with NTs? It this a next week thing or is this like Win32, last year? 2) Are the unresolved issues with NTs the result of the complexity of the problem, or just the result of the community not paying attention to the patch until after feature-freeze? 3) Is there some majority in our community who would rather hold back 7.5 by several weeks in order to get NTs now instead of mid-2005? Based on (1) and (2), NTs are starting to feel like Win32 did last year to me. Please don't mistake me; I would very, very much like to have them as someone with half a million lines of PL/pgSQL in my past and half-a-dozen J2EE+PostgreSQL clients. It's a very hard problem and Alvaro has been working like a demon to resolve it. However, I'm beginning to think that it is a *very* hard problem and Alvaro has had only about 2 months to work on it. There are just too many things -- cursors, functions, exceptions, syntax -- that we have only begun to address. I'm very much afraid of a repeat of last year, where we waited an extra month for a Win32 version that was going to take an extra year. So I'm thinking we hold them back. That we try to get out 7.5 by October this year, and target 7.6, on a short release cycle, for March. We would already have 3 new features for 7.6, and I'm sure more will show up by January. This would also resolve the issue of shifting our release cycles. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Release planning
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Release planning
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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Release planning (was: Re: Status report)
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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Release planning
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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Release planning
-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 [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFA9J89qp6r/MVGlwwRAh6CAKDCJhuomf8hWbHMHGqrYfCGi5QzxQCfT4Hs feHVoYbFW0tq6BwJtFxy+EE= =BmHk -END PGP SIGNATURE- ---(end of broadcast)--- TIP 8: explain analyze is your friend
