Re: [HACKERS] Release cycle length
Any chance you might be able to put together a HOWTO on this? I think it would be extremely valuable to a lot of people. On Tue, Nov 25, 2003 at 11:25:34PM -0500, Andrew Sullivan wrote: On Mon, Nov 24, 2003 at 11:08:44PM -0600, Jim C. Nasby wrote: Has anyone looked at using replication as a migration method? If Looked at? Sure. Heck, I've done it. Yes, it works. Is it painless? Well, that depends on whether you think using erserver is painless. ;-) It's rather less downtime than pg_dump | psql, I'll tell you. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Member: Triangle Fraternity, Sports Car Club of America Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(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 cycle length
On Mon, Nov 24, 2003 at 11:08:44PM -0600, Jim C. Nasby wrote: Has anyone looked at using replication as a migration method? If Looked at? Sure. Heck, I've done it. Yes, it works. Is it painless? Well, that depends on whether you think using erserver is painless. ;-) It's rather less downtime than pg_dump | psql, I'll tell you. A -- Andrew Sullivan 204-4141 Yonge Street Afilias CanadaToronto, Ontario Canada [EMAIL PROTECTED] M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Release cycle length
On Fri, Nov 21, 2003 at 01:32:38PM -0500, Jan Wieck wrote: bootstrap mode to apply the changes, could be an idea to think of. It would still require some downtime, but nobody can avoid that when replacing the postgres binaries anyway, so that's not a real issue. As long as it eliminates dump, initdb, reload it will be acceptable. Has anyone looked at using replication as a migration method? If replication can be setup in such a way that you can replicate from an old version to a new version, you can use that to build the new version of the database on a seperate machine/instance while the old version is still live. With some sophisticated middleware, you could theoretically migrate without any downtime. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Member: Triangle Fraternity, Sports Car Club of America Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(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 cycle length
Quoth [EMAIL PROTECTED] (Jim C. Nasby):
On Fri, Nov 21, 2003 at 01:32:38PM -0500, Jan Wieck wrote:
bootstrap mode to apply the changes, could be an idea to think of. It
would still require some downtime, but nobody can avoid that when
replacing the postgres binaries anyway, so that's not a real issue. As
long as it eliminates dump, initdb, reload it will be acceptable.
Has anyone looked at using replication as a migration method? If
replication can be setup in such a way that you can replicate from an
old version to a new version, you can use that to build the new version
of the database on a seperate machine/instance while the old version is
still live. With some sophisticated middleware, you could theoretically
migrate without any downtime.
The idea has indeed been looked at, and seems pretty feasible.
It would certainly take some sophisticated middleware to totally evade
downtime. But replicating from old version to new version does
have the merit of keeping the downtime to fairly much a minimum.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','cbbrowne.com').
http://www3.sympatico.ca/cbbrowne/x.html
:FATAL ERROR -- VECTOR OUT OF HILBERT SPACE
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Release cycle length
On Fri, Nov 21, 2003 at 09:38:50AM +0800, Christopher Kings-Lynne wrote: Yeah, I think the main issue in all this is that for real production sites, upgrading Postgres across major releases is *painful*. We have to find a solution to that before it makes sense to speed up the major-release cycle. Well, I think one of the simplest is to do a topological sort of objects in pg_dump (between object classes that need it), AND regression testing for pg_dump :) One of the most complex would be to avoid the need of pg_dump for upgrades ... -- Alvaro Herrera ([EMAIL PROTECTED]) I call it GNU/Linux. Except the GNU/ is silent. (Ben Reiter) ---(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 cycle length
Alvaro Herrera wrote: On Fri, Nov 21, 2003 at 09:38:50AM +0800, Christopher Kings-Lynne wrote: Yeah, I think the main issue in all this is that for real production sites, upgrading Postgres across major releases is *painful*. We have to find a solution to that before it makes sense to speed up the major-release cycle. Well, I think one of the simplest is to do a topological sort of objects in pg_dump (between object classes that need it), AND regression testing for pg_dump :) One of the most complex would be to avoid the need of pg_dump for upgrades ... We don't need a simple way, we need a way to create some sort of catalog diff and a safe way to apply that to an existing installation during the upgrade. I think with a shutdown postmaster, a standalone backend used to check that no conflicts exist in any DB, then using the new backend in bootstrap mode to apply the changes, could be an idea to think of. It would still require some downtime, but nobody can avoid that when replacing the postgres binaries anyway, so that's not a real issue. As long as it eliminates dump, initdb, reload it will be acceptable. 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 cycle length
Jan Wieck [EMAIL PROTECTED] writes: Alvaro Herrera wrote: One of the most complex would be to avoid the need of pg_dump for upgrades ... We don't need a simple way, we need a way to create some sort of catalog diff and a safe way to apply that to an existing installation during the upgrade. I still think that pg_upgrade is the right idea: load a schema dump from the old database into the new one, then transfer the user data files and indexes via cheating (doubly linking, if possible). Obviously there is a lot of work still to make this happen reliably, but we have seen proof-of-concept some while ago, whereas catalog diffs are pie in the sky IMHO. (You could not use either the old postmaster version or the new version to apply such a diff...) A big advantage of the pg_upgrade concept in my mind is that if it fails partway through, you need have made no changes to the original installation. Any mid-course problem with an in-place-diff approach leaves you completely screwed :-( regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Release cycle length
Hello hackers Sorry when I am talking to the gurus... There is a database, which has a concept called Transportable Tablespace (TTS). Would it not be a verry easy and fast solution to just do this with the Tables, Index and all non catalog related files. - You create a new db cluster (e.g 8.0). - Generate a TTS export skript. - Shut the (old) db-cluster (files should be consistent now, ev. do something with the log files before). - Move the files (eventually not needed) and - plug it in to the new db cluster (via the export skript). Expected downtime (without moving data files) 5-10 minutes. Regards Oli --- Oli Sennhauser Database-Engineer (Oracle PostgreSQL) Rebenweg 6 CH - 8610 Uster / Switzerland Phone (+41) 1 940 24 82 or Mobile (+41) 79 450 49 14 e-Mail [EMAIL PROTECTED] Website http://mypage.bluewin.ch/shinguz/PostgreSQL/ Secure (signed/encrypted) e-Mail with a Free Personal SwissSign ID: http://www.swisssign.ch Import the SwissSign Root Certificate: http://swisssign.net/cgi-bin/trust/import smime.p7s Description: S/MIME Cryptographic Signature
Re: [HACKERS] Release cycle length
Jan Wieck [EMAIL PROTECTED] writes: On Tue, 18 Nov 2003, Peter Eisentraut wrote: The time from release 7.3 to release 7.4 was 355 days, an all-time high. We really need to shorten that. I don't see much of a point for a shorter release cycle as long as we don't get rid of the initdb requirement for releases that don't change the system catalog structure. All we gain from that is spreading out the number of different versions used in production. Yeah, I think the main issue in all this is that for real production sites, upgrading Postgres across major releases is *painful*. We have to find a solution to that before it makes sense to speed up the major-release cycle. By the same token, I'm not sure that there's much of a market for development releases --- people who find a 7.3-7.4 upgrade painful aren't going to want to add additional upgrades to incompatible intermediate states. If we could fix that, there'd be more interest. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Release cycle length
Kevin Brown [EMAIL PROTECTED] writes: ... That's why the release methodology used by the Linux kernel development team is a reasonable one. I do not think we have the manpower to manage multiple active development branches. The Postgres developer community is a fraction of the size of the Linux community; if we try to adopt what they do we'll just drown in work. It's hard enough to deal with the existing level of commitment to back-patching one stable release --- I know that we miss back-patching bug fixes that probably should have been back-patched. And the stuff that does get back-patched isn't really tested to the level that it ought to be, which discourages us from applying fixes to the stable branch if they are too large to be obviously correct. I don't see manpower emerging from the woodwork to fix those problems. If we were doing active feature development in more than one branch I think our process would break down completely. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Release cycle length
Larry Rosenman [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: 1. Start platform testing on day 1 of beta. Last minute fixes for AIX or UnixWare are really becoming old jokes. The only reason we had last minute stuff for UnixWare this time was the timing of PG's release and the UP3 release from SCO. Yes. The late fixes for OS X also arose from the fact that Apple released a new OS X version late in our beta cycle. I don't think it's reasonable to complain that there was insufficient port testing done earlier; the issues didn't come from that. I do agree with the opinion that our beta cycles are getting too long, and that it's not clear we are getting any additional reliability out of the longer time period. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Release cycle length
Yeah, I think the main issue in all this is that for real production sites, upgrading Postgres across major releases is *painful*. We have to find a solution to that before it makes sense to speed up the major-release cycle. Well, I think one of the simplest is to do a topological sort of objects in pg_dump (between object classes that need it), AND regression testing for pg_dump :) Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Release cycle length
Marc G. Fournier wrote: On Tue, 18 Nov 2003, Peter Eisentraut wrote: The time from release 7.3 to release 7.4 was 355 days, an all-time high. We really need to shorten that. We already have a number of significant improvements in 7.5 now, and several good ones coming up in the next few weeks. We cannot let people wait 1 year for that. I suggest that we aim for a 6 month cycle, consisting of approximately 4 months of development and 2 months of cleanup. So the start of the next beta could be the 1st of March. What do you think? That is the usual goal *nod* Same goal we try for each release, and never quite seem to get there ... we'll try 'yet again' with v7.5 though, as we always do :) I don't see much of a point for a shorter release cycle as long as we don't get rid of the initdb requirement for releases that don't change the system catalog structure. All we gain from that is spreading out the number of different versions used in production. 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Release cycle length
On Tue, 2003-11-18 at 04:36, Marc G. Fournier wrote: On Tue, 18 Nov 2003, Peter Eisentraut wrote: 0. As you say, make it known to the public. Have people test their in-development applications using a beta. and how do you propose we do that? I think this is the hard part ... other then the first beta, I post a note out to -announce and -general that the beta's have been tag'd and bundled for download ... I know Sean does up a 'devel' port for FreeBSD, but I don't believe any of the RPM/deb maintainers do anything until the final release ... I do in fact build debs of the beta and rc releases. These have gone into the experimental archive in Debian and are announced on Debian lists. I even posted an announcement to pgsql-general, on 10th October for example. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C A Song for the sabbath day. It is a good thing to give thanks unto the LORD, and to sing praises unto thy name, O most High. Psalms 92:1 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Release cycle length
0. As you say, make it known to the public. Have people test their in-development applications using a beta. and how do you propose we do that? I think this is the hard part ... other then the first beta, I post a note out to -announce and -general that the beta's have been tag'd and bundled for download ... I know Sean does up a 'devel' port for FreeBSD, but I don't believe any of the RPM/deb maintainers do anything until the final release ... Incidentally, the reason that I created the -devel port is because I needed some of the features now and didn't want to wait for a release. As things stand, I'm getting roughly 50-100 downloads a day of my -devel snapshots, which leads me to believe that there is some interest in having the release engineering team push features out the door more quickly. My eye on the pgsql repo isn't perfect, but I know I'm not the only one using it in production. 5. If need be, have a release management team that manages 0-4. Core does that, but we just don't feel that being totally rigid is (or has ever been) a requirement ... but, if you can provide suggestions on points 0 and 3, we're all ears ... You've got FreeBSD blood in you, you know that [EMAIL PROTECTED] is the same as [EMAIL PROTECTED] + [EMAIL PROTECTED] + [EMAIL PROTECTED] + [EMAIL PROTECTED] I think that [EMAIL PROTECTED]'s big reason for wanting to have long release cycles is to minimize the time that pgsql developers spend with their re@ and qa@ hats on. Truth be told, pgsql's code quality in the tree is so high that a snapshot of HEAD is almost as good as a release... the difference being the amount of attention spent on detail, docs, finishing touches/polish. For the # of lines of code that go into pgsql, it's nearly bug free over 95% of the time which means to me with an releng hat on, that pgsql could stand to increase the rate of releases so long as the developers can stomach doing the extra merges from HEAD to the stable branch for feature additions or possibly watching micro version numbers increment faster than they have historically. For all intents and purposes, pgsql's releases are stellar and the Pg team makes every release very important to most everyone, where important is defined as containing features useful for everyone: as opposed to a re@ release often model where releases don't necessarily useful features to a majority and just lead to upgrade thrashing which is costly to organizations. Food for thought... nothing conclusive here. -sc -- Sean Chittenden ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Release cycle length
On Mon, Nov 17, 2003 at 20:08:41 -0500, Neil Conway [EMAIL PROTECTED] wrote: Peter Eisentraut [EMAIL PROTECTED] writes: The time from release 7.3 to release 7.4 was 355 days, an all-time high. We really need to shorten that. Why is that? End users will find it useful. I started using 7.4 from CVS early on because check constraints for domains were available. With a long release cycle you have to wait a long time to get any of the features in a release when some of them may have been developed early in the release cycle. ---(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 cycle length
... Does anyone have a comparison of how many lines of code were added in this release compared to previous? 7.2.4: 456204 lines of code in 1021 files 7.3.4: 480491 lines of code in 1012 files 7.4: 554567 lines of code in 1128 files (boah!) I used a fresh extracted source-directory and executed 'find postgresql-7.xxx -name '*.c' - o -name '*.h'|wc -l' and 'find postgresql-7.xxx -name '*.c' - o -name '*.h'|xargs cat|wc -l' Tommi Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Release cycle length
On Tue, Nov 18, 2003 at 02:33:41PM +0100, Tommi Maekitalo wrote: ... Does anyone have a comparison of how many lines of code were added in this release compared to previous? 7.2.4: 456204 lines of code in 1021 files 7.3.4: 480491 lines of code in 1012 files 7.4: 554567 lines of code in 1128 files (boah!) I used SLOCcount by David A. Wheeler at some point on various releases (including 7.1.3 IIRC) and at some point the number of lines actually _decreased_. I didn't look into it in more detail, but I think the number of lines of code doesn't even come near to telling the whole story. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) You liked Linux a lot when he was just the gawky kid from down the block mowing your lawn or shoveling the snow. But now that he wants to date your daughter, you're not so sure he measures up. (Larry Greenemeier) ---(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 cycle length
Marc G. Fournier wrote: On Tue, 18 Nov 2003, Peter Eisentraut wrote: 0. As you say, make it known to the public. Have people test their in-development applications using a beta. and how do you propose we do that? I think this is the hard part ... other then the first beta, I post a note out to -announce and -general that the beta's have been tag'd and bundled for download ... I know Sean does up a 'devel' port for FreeBSD, but I don't believe any of the RPM/deb maintainers do anything until the final release ... 1. Start platform testing on day 1 of beta. Last minute fixes for AIX or UnixWare are really becoming old jokes. then each beta will have to be re-certified for that beta, up until release ... doable, but I don't think you'll find many that will bother until we are close to release ... 2. Have a complete account of the changes available at the start of beta, so people know what to test. Bruce, when do you do your initial HISTORY file? Something to move to the start of beta, if not? I see beta starting on: revision 1.277 date: 2003/08/04 22:30:30; author: pgsql; state: Exp; lines: +3 -3 change tag to 7.4beta1 and update the Copyright to 2003 Guess what folks? We are now in Beta!! and 7.4 HISTORY updated on: revision 1.196 date: 2003/08/03 23:26:05; author: momjian; state: Exp; lines: +324 -26 Update HISTORY file for 7.4. so the HISTORY file was updated the day before beta started. I haven't always been good about this, but I am now. -- 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 7: don't forget to increase your free space map settings
Re: [pgsql-www] [HACKERS] Release cycle length
Guys, I agree with Neil ... it's not the length of the development part of the cycle, it's the length of the beta testing. I do think an online bug tracker (bugzilla or whatever) would help. I also think that having a person in charge of testing would help as well ... no biggie, just someone whose duty it is to e-mail people in the community and ask about the results of testing, especially on the more obscure ports. I think a few e-mail reminders would do a *lot* to speed things up. But I'm not volunteering for this job; managing the release PR is herding cats enough! I also contributed to the delays on this release because it took longer than I expected to get the PR machinery started. We have a sort of system now, though, and the next release should be easier. HOWEVER, a release cycle of *less than 6 months* would kill the advocacy vols if we wanted the same level of publicity. I do support the idea of dev releases. For example, if there was a dev release of PG+ARC as soon as Jan is done with it, I have one client would would be willing to test it against a simulated production load on pretty heavy-duty hardware. (Oddly enough, my problem in doing more testing myself is external to PostgreSQL; most of our apps are PHP apps and you can't compile PHP against two different versions of PostgreSQL on the same server. Maybe with User Mode Linux I'll be able to do more testing now.) -- 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: [pgsql-www] [HACKERS] Release cycle length
On Tue, Nov 18, 2003 at 09:42:31AM -0800, Josh Berkus wrote: (Oddly enough, my problem in doing more testing myself is external to PostgreSQL; most of our apps are PHP apps and you can't compile PHP against two different versions of PostgreSQL on the same server. Maybe with User Mode Linux I'll be able to do more testing now.) I'm not sure UML would help you here. I think you'd be better trying to run Apache in a chrooted environment, PHP and PostgreSQL included. You don't need another kernel, but another set of libraries. BTW, I think UMLSIM (umlsim.sf.net) could help to play the unplug-the-server game. In theory you could rewrite the block subsystem to fail, simulating a real disk failure and possible a system shutdown. I don't have time to do it myself right now however ... -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Find a bug in a program, and fix it, and the program will work today. Show the program how to find and fix a bug, and the program will work forever (Oliver Silfridge) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-www] [HACKERS] Release cycle length
Josh Berkus wrote: Guys, I agree with Neil ... it's not the length of the development part of the cycle, it's the length of the beta testing. I do think an online bug tracker (bugzilla or whatever) would help. I also think that having a person in charge of testing would help as well ... no biggie, just someone whose duty it is to e-mail people in the community and ask about the results of testing, especially on the more obscure ports. I think a few e-mail reminders would do a *lot* to speed things up. But I'm not volunteering for this job; managing the release PR is herding cats enough! Maybe some sort of automated distributed build farm would be a good idea. Check out http://build.samba.org/about.html to see how samba does it (much lighter than the Mozilla tinderbox approach). We wouldn't need to be as intensive as they appear to be - maybe a once or twice a day download and test run would do the trick, but it could pick up lots of breakage fairly quickly. That is not to say that more intensive testing isn't also needed on occasion. cheers andrew ---(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: [pgsql-www] [HACKERS] Release cycle length
On Tue, 18 Nov 2003, Andrew Dunstan wrote: Josh Berkus wrote: Guys, I agree with Neil ... it's not the length of the development part of the cycle, it's the length of the beta testing. I do think an online bug tracker (bugzilla or whatever) would help. I also think that having a person in charge of testing would help as well ... no biggie, just someone whose duty it is to e-mail people in the community and ask about the results of testing, especially on the more obscure ports. I think a few e-mail reminders would do a *lot* to speed things up. But I'm not volunteering for this job; managing the release PR is herding cats enough! Maybe some sort of automated distributed build farm would be a good idea. Check out http://build.samba.org/about.html to see how samba does it (much lighter than the Mozilla tinderbox approach). We wouldn't need to be as intensive as they appear to be - maybe a once or twice a day download and test run would do the trick, but it could pick up lots of breakage fairly quickly. That is not to say that more intensive testing isn't also needed on occasion. Check the archives on this, as its been hashed out already once at least ... I think the big issue/problem is that nobody seems able (or wants) to come up with a script that could be setup in cron on machines to do this ... something simple that would dump the output to a log file and, if regression tests failed, email'd the machine owner that it needs to be checked would do, I would think ... ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Release cycle length
On Tue, Nov 18, 2003 at 12:36:11AM -0400, Marc G. Fournier wrote: On Tue, 18 Nov 2003, Peter Eisentraut wrote: 0. As you say, make it known to the public. Have people test their in-development applications using a beta. and how do you propose we do that? I think this is the hard part ... other then the first beta, I post a note out to -announce and -general that the beta's have been tag'd and bundled for download ... I know Sean does up a 'devel' port for FreeBSD, but I don't believe any of the RPM/deb maintainers do anything until the final release ... For what it is worth, I try to promote the beta testing on general bits. I also invite people to write articles for me. To highlight a feature or concept or just to egg people on in a short article by a guest to general bits is very appropriate. My audience might not be core hackers, but getting the larger user group to participate as well as prepare for conversion is something I can help promote. (Just contact me to submit articles for publication--the invitation is always open.) --elein = [EMAIL PROTECTED] Varlena, LLC www.varlena.com PostgreSQL Consulting, Support Training PostgreSQL General Bits http://www.varlena.com/GeneralBits/ = I have always depended on the [QA] of strangers. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-www] [HACKERS] Release cycle length
HOWEVER, a release cycle of *less than 6 months* would kill the advocacy vols if we wanted the same level of publicity. I do support the idea of dev releases. For example, if there was a dev release of PG+ARC as soon as Jan is done with it, I have one client would would be willing to test it against a simulated production load on pretty heavy-duty hardware. Can't we have nightly builds always available? Why can't they just use the CVS version? (Oddly enough, my problem in doing more testing myself is external to PostgreSQL; most of our apps are PHP apps and you can't compile PHP against two different versions of PostgreSQL on the same server. Maybe with User Mode Linux I'll be able to do more testing now.) I'd be willing to give testing coordination a go, not sure where I'd begin though. Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-www] [HACKERS] Release cycle length
On Wed, 19 Nov 2003, Christopher Kings-Lynne wrote: HOWEVER, a release cycle of *less than 6 months* would kill the advocacy vols if we wanted the same level of publicity. I do support the idea of dev releases. For example, if there was a dev release of PG+ARC as soon as Jan is done with it, I have one client would would be willing to test it against a simulated production load on pretty heavy-duty hardware. Can't we have nightly builds always available? Why can't they just use the CVS version? We do do nightly builds ... have for years now ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Release cycle length
The time from release 7.3 to release 7.4 was 355 days, an all-time high. We really need to shorten that. We already have a number of significant improvements in 7.5 now, and several good ones coming up in the next few weeks. We cannot let people wait 1 year for that. I suggest that we aim for a 6 month cycle, consisting of approximately 4 months of development and 2 months of cleanup. So the start of the next beta could be the 1st of March. What do you think? -- Peter Eisentraut [EMAIL PROTECTED] ---(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 cycle length
On Tue, 18 Nov 2003, Peter Eisentraut wrote: The time from release 7.3 to release 7.4 was 355 days, an all-time high. We really need to shorten that. We already have a number of significant improvements in 7.5 now, and several good ones coming up in the next few weeks. We cannot let people wait 1 year for that. I suggest that we aim for a 6 month cycle, consisting of approximately 4 months of development and 2 months of cleanup. So the start of the next beta could be the 1st of March. What do you think? That is the usual goal *nod* Same goal we try for each release, and never quite seem to get there ... we'll try 'yet again' with v7.5 though, as we always do :) ---(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 cycle length
Marc G. Fournier writes: That is the usual goal *nod* Same goal we try for each release, and never quite seem to get there ... we'll try 'yet again' with 7.5 though, as we always do :) I don't see how we could have tried for a 4-month development period and ended up with an 8-month period. Something went *really* wrong there. Part of that may have been that few people were actually aware of that schedule. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Release cycle length
On Tue, 18 Nov 2003, Peter Eisentraut wrote: Marc G. Fournier writes: That is the usual goal *nod* Same goal we try for each release, and never quite seem to get there ... we'll try 'yet again' with 7.5 though, as we always do :) I don't see how we could have tried for a 4-month development period and ended up with an 8-month period. Something went *really* wrong there. Part of that may have been that few people were actually aware of that schedule. Everyone on -hackers should have been aware of it, as its always discussed at the end of the previous release cycle ... and I don't think we've hit a release cycle yet that has actually stayed in the 4 month period :( Someone is always 'just sitting on something that is almost done' at the end that pushes it further then originally planned ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Release cycle length
Just did a quick search on archives, and the original plan was for a release in mid-2003, which means the beta would have been *at least* a month before that, so beta starting around May: http://archives.postgresql.org/pgsql-hackers/2002-11/msg00975.php On Mon, 17 Nov 2003, Marc G. Fournier wrote: On Tue, 18 Nov 2003, Peter Eisentraut wrote: Marc G. Fournier writes: That is the usual goal *nod* Same goal we try for each release, and never quite seem to get there ... we'll try 'yet again' with 7.5 though, as we always do :) I don't see how we could have tried for a 4-month development period and ended up with an 8-month period. Something went *really* wrong there. Part of that may have been that few people were actually aware of that schedule. Everyone on -hackers should have been aware of it, as its always discussed at the end of the previous release cycle ... and I don't think we've hit a release cycle yet that has actually stayed in the 4 month period :( Someone is always 'just sitting on something that is almost done' at the end that pushes it further then originally planned ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Release cycle length
Peter Eisentraut [EMAIL PROTECTED] writes: The time from release 7.3 to release 7.4 was 355 days, an all-time high. We really need to shorten that. Why is that? -Neil ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Release cycle length
Marc G. Fournier writes: Just did a quick search on archives, and the original plan was for a release in mid-2003, which means the beta would have been *at least* a month before that, so beta starting around May: http://archives.postgresql.org/pgsql-hackers/2002-11/msg00975.php That was a Bruce Momjian estimate mentioned in passing, not an affirmed plan. Also, I think Bruce's estimates are notoriously off by years. ;-) -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Release cycle length
Neil Conway writes: Peter Eisentraut [EMAIL PROTECTED] writes: The time from release 7.3 to release 7.4 was 355 days, an all-time high. We really need to shorten that. Why is that? First, if you develop something today, the first time users would realistically get a hand at it would be January 2005. Do you want that? Don't you want people to use your code? We fix problems, but people must wait a year for the fix? Second, the longer a release cycle, the more problems amass. People just forget what they were doing in the beginning, no one is around to fix the problems introduced earlier, no one remembers anything when it comes time to write release notes. The longer you develop, the more parallel efforts are underway, and it becomes impossible to synchronize them to a release date. People are not encouraged to provide small, well-thought-out, modular improvements. Instead, they break everything open and worry about it later. At the end, it's always a rush to close these holes. Altogether, it's a loss for both developers and users. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Release cycle length
The time from release 7.3 to release 7.4 was 355 days, an all-time high. We really need to shorten that. We already have a number of significant improvements in 7.5 now, and several good ones coming up in the next few weeks. We cannot let people wait 1 year for that. I suggest that we aim for a 6 month cycle, consisting of approximately 4 months of development and 2 months of cleanup. So the start of the next beta could be the 1st of March. What do you think? So long as pg_dump object ordering is an early fix to make upgrades rather more painless, I'm all for it :) Does anyone have a comparison of how many lines of code were added in this release compared to previous? Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Release cycle length
Everyone on -hackers should have been aware of it, as its always discussed at the end of the previous release cycle ... and I don't think we've hit a release cycle yet that has actually stayed in the 4 month period :( Someone is always 'just sitting on something that is almost done' at the end that pushes it further then originally planned ... I think that the core just need to be tough on it, that's all. If we have pre-published target dates, then everyone knows if they can get their code in or not for that date. Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Release cycle length
Hello, Personally I am for long release cycles, at least for major releases. In fact as of 7.4 I think there should possibly be a slow down in releases with more incremental releases (minor releases) throughout the year. People are running their companies and lives off of PostgreSQL, they should be able to rely on a specific feature set, and support from the community for longer. Sincerely, Joshua Drake Peter Eisentraut wrote: Neil Conway writes: Peter Eisentraut [EMAIL PROTECTED] writes: The time from release 7.3 to release 7.4 was 355 days, an all-time high. We really need to shorten that. Why is that? First, if you develop something today, the first time users would realistically get a hand at it would be January 2005. Do you want that? Don't you want people to use your code? We fix problems, but people must wait a year for the fix? Second, the longer a release cycle, the more problems amass. People just forget what they were doing in the beginning, no one is around to fix the problems introduced earlier, no one remembers anything when it comes time to write release notes. The longer you develop, the more parallel efforts are underway, and it becomes impossible to synchronize them to a release date. People are not encouraged to provide small, well-thought-out, modular improvements. Instead, they break everything open and worry about it later. At the end, it's always a rush to close these holes. Altogether, it's a loss for both developers and users. -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Release cycle length
On Tue, 18 Nov 2003, Christopher Kings-Lynne wrote: Everyone on -hackers should have been aware of it, as its always discussed at the end of the previous release cycle ... and I don't think we've hit a release cycle yet that has actually stayed in the 4 month period :( Someone is always 'just sitting on something that is almost done' at the end that pushes it further then originally planned ... I think that the core just need to be tough on it, that's all. If we have pre-published target dates, then everyone knows if they can get their code in or not for that date. Right now, I believe we are looking at an April 1st beta, and a May 1st related ... those are, as always, *tentative* dates that will become more fine-tuned as those dates become nearer ... April 1st, or 4 mos from last release, tends to be what we aim for with all releases ... as everyone knows, we don't necessarily acheive it, but ... Actually, historically, it looks like we've always been close to 12 months between releases ... 7.0-7.1: ~11mos, 7.1-7.2: ~10mos, 7.2-7.3: ~9 mos, and 7.3-7.4: ~12mos ... so, on average, we're dealing with an ~10mos release cycle for the past 3 years ... svr1# ls -l */postgresql-7.?.tar.gz -rw-rw-r-- 1 pgsql pgsql 9173732 May 9 2000 v7.0/postgresql-7.0.tar.gz -rw-r--r-- 1 pgsql pgsql 8088678 Apr 13 2001 v7.1/postgresql-7.1.tar.gz -rw-r--r-- 1 pgsql pgsql 9180168 Feb 4 2002 v7.2/postgresql-7.2.tar.gz -rw-r--r-- 1 pgsql pgsql 11059455 Nov 27 2002 v7.3/postgresql-7.3.tar.gz -rw-r--r-- 1 pgsql pgsql 12311256 Nov 16 17:57 v7.4/postgresql-7.4.tar.gz ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Release cycle length
Right now, I believe we are looking at an April 1st beta, and a May 1st related ... those are, as always, *tentative* dates that will become more fine-tuned as those dates become nearer ... April 1st, or 4 mos from last release, tends to be what we aim for with all releases ... as everyone knows, we don't necessarily acheive it, but Make it April 2nd, otherwise everyone will think it's a joke :P Chris ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Release cycle length
Joshua D. Drake [EMAIL PROTECTED] writes: Hello, Personally I am for long release cycles, at least for major releases. In fact as of 7.4 I think there should possibly be a slow down in releases with more incremental releases (minor releases) throughout the year. That would pretty much mean changing the minor releases only for serious bugfixes philosphy. Is that what you are advocating? People are running their companies and lives off of PostgreSQL, they should be able to rely on a specific feature set, and support from the community for longer. If 7.3.4 works for you, there's nothing to stop you running it until the end of time... If you can't patch in bugfixes yourself, you should be willing to pay for support. Commercial companies like Red Hat don't support their releases indefinitely for free; why should the PG community be obligated to? Also, we very rarely remove features--AUTOCOMMIT on the server is about the only one I can think of. -Doug ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Release cycle length
Peter Eisentraut [EMAIL PROTECTED] writes: First, if you develop something today, the first time users would realistically get a hand at it would be January 2005. Do you want that? Don't you want people to use your code? Sure :-) But I don't mind a long release cycle if it is better for users. We fix problems, but people must wait a year for the fix? A couple points: (a) Critical problems can of course be fixed via point releases in the current stable release series (b) As PostgreSQL gets more mature, the number of absolutely show stopping features or bug fixes in a new release gets smaller. For example, I'd argue that neither 7.3 or 7.4 include a single feature that is as important as 7.2's lazy VACUUM or 7.1's WAL. There are lots of great features, but the set of absolutely essential new features tends to grow smaller over time. I'd wager that for the vast majority of our user base, PostgreSQL already works well. (c) As PostgreSQL gets more mature, putting out stable, production-worthy releases becomes even more important. In theory, longer release cycles contribute to higher quality releases: we have more time to implement new features properly, polish rough edges and document things, test and find bugs, and ensure that features we've implemented earlier in the release cycle are properly thought out, and so forth. Note that whether or not we are using those 355 days effectively is another story -- it may well be true that there are we could make parts of the development process much more efficient. Furthermore, longer release cycles reduce, to some degree, the pain of upgrades. Unless we make substantial improvements to the upgrade story any time soon, I wouldn't be surprised if many DBAs are relieved at only needing to upgrade once a year. The longer you develop, the more parallel efforts are underway, and it becomes impossible to synchronize them to a release date. I think this is inherent to the way PostgreSQL is developed: Tom has previously compared PostgreSQL release scheduling to herding cats :-) As long as much of the work on the project is done by volunteers in their spare time, ISTM that coordinating everyone toward a single release date is going to be difficult, if not impossible. The length of the release cycle doesn't really effect this, IMHO. People are not encouraged to provide small, well-thought-out, modular improvements. I agree we can always do better when it comes to code quality. I think the NetBSD team puts it well: Some systems seem to have the philosophy of If it works, it's right. In that light NetBSD could be described as It doesn't work /unless/ it's right. That said, I don't see how this is related to the release schedule. In fact, one could argue that a longer release schedule gives new features a longer gestation period during which developers can ensure that they are well-thought out and implemented properly. Altogether, it's a loss for both developers and users. I don't think it's nearly as clear-cut as that. Both types of release scheduling have their benefits and their drawbacks. My main point is really that a short release cycle is not an unqualified good (not to mention that in the past we've been completely unable to actually *execute* a short release cycle, making this whole discussion a little academic). -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Release cycle length
Marc G. Fournier writes: Right now, I believe we are looking at an April 1st beta, and a May 1st related ... those are, as always, *tentative* dates that will become more fine-tuned as those dates become nearer ... OK, here start the problems. Development already started, so April 1st is already 5 months development. Add 1 month because no one is willing to hold people to these dates. So that's 6 months. Then for 6 months of development, you need at least 2 months of beta. So we're already in the middle of July, everyone is on vacation, and we'll easily reach the 9 months -- instead of 6. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Release cycle length
Peter Eisentraut wrote: Marc G. Fournier writes: Right now, I believe we are looking at an April 1st beta, and a May 1st related ... those are, as always, *tentative* dates that will become more fine-tuned as those dates become nearer ... OK, here start the problems. Development already started, so April 1st is already 5 months development. Add 1 month because no one is willing to hold people to these dates. So that's 6 months. Then for 6 months of development, you need at least 2 months of beta. So we're already in the middle of July, everyone is on vacation, and we'll easily reach the 9 months -- instead of 6. Do you think that 2 months for beta is realistic? Tom announced feature freeze on July 1. http://archives.postgresql.org/pgsql-hackers/2003-07/msg00040.php So 7.4 took about 4.5 months to get from feature freeze to release. I think feature freeze is the important date that developers of new features need to concern themselves with. I agree with Peter's other comment, that the longer the development cycle, the longer the beta / bug shakeout period, perhaps a shorter dev cycle would yield a shorter beta period, but perhaps it would also result in a less solid release. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Release cycle length
On Tue, 18 Nov 2003, Peter Eisentraut wrote: Marc G. Fournier writes: Right now, I believe we are looking at an April 1st beta, and a May 1st related ... those are, as always, *tentative* dates that will become more fine-tuned as those dates become nearer ... OK, here start the problems. Development already started, so April 1st is already 5 months development. Add 1 month because no one is willing to hold people to these dates. So that's 6 months. Then for 6 months of development, you need at least 2 months of beta. So we're already in the middle of July, everyone is on vacation, and we'll easily reach the 9 months -- instead of 6. 'K, Sept 1st it is then ... sounds reasonable to me :) ---(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 cycle length
Matthew T. O'Connor [EMAIL PROTECTED] writes: So 7.4 took about 4.5 months to get from feature freeze to release. I think feature freeze is the important date that developers of new features need to concern themselves with. Rather than the length of the release cycle, I think it's the length of the beta cycle that we should focus on improving. IMHO, we should try to make the beta process more efficient: sometimes I get the impression that the beta process just drags on and on, without the extra time resulting in a huge improvement in the reliability of the .0 release (witness the fact that all the .0 releases I can remember have had a *lot* of serious bugs in them -- we can't catch everything of course, but I think there is definitely room for improvement). That said, I'm not really sure how we can make better use of the beta period. One obvious improvement would be making the beta announcements more visible: the obscurity of the beta process on www.postgresql.org for 7.4 was pretty ridiculous. Does anyone else have a suggestion on what we can do to produce a more reliable .0 release in less time? -Neil ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Release cycle length
Neil Conway wrote: Peter Eisentraut [EMAIL PROTECTED] writes: First, if you develop something today, the first time users would realistically get a hand at it would be January 2005. Do you want that? Don't you want people to use your code? Sure :-) But I don't mind a long release cycle if it is better for users. Given that users can run whatever they like, it's not clear that a long release cycle is better for users. (c) As PostgreSQL gets more mature, putting out stable, production-worthy releases becomes even more important. In theory, longer release cycles contribute to higher quality releases: we have more time to implement new features properly, polish rough edges and document things, test and find bugs, and ensure that features we've implemented earlier in the release cycle are properly thought out, and so forth. On the other hand, the longer you wait to release a new feature, the longer it will be before you get your REAL testing done. You don't want to release something that hasn't at least been looked over and checked out by the development community first, of course, but waiting beyond that point to release a new version of PG doesn't help you that much, because most people aren't going to run the latest CVS version -- they'll run the latest released version, whatever that may be. So the time between the testing phase for the feature you implement and the version release is essentially dead time for testing of that feature, because most developers have moved on to working on and/or testing something else. That's why the release methodology used by the Linux kernel development team is a reasonable one. Because the development releases are still releases, people who wish to be more on the bleeding edge can do so without having to grab the source from CVS and compile it themselves. And package maintainers are more likely to package up the development version if it's given to them in a nice, prepackaged format, even if it's just a source tarball. Note that whether or not we are using those 355 days effectively is another story -- it may well be true that there are we could make parts of the development process much more efficient. Furthermore, longer release cycles reduce, to some degree, the pain of upgrades. Unless we make substantial improvements to the upgrade story any time soon, I wouldn't be surprised if many DBAs are relieved at only needing to upgrade once a year. But DBAs only need to upgrade as often as they feel like. Any reasonable distribution will give them an option of using either the stable version or the development version anyway, if we're talking about prepackaged versions. The longer you develop, the more parallel efforts are underway, and it becomes impossible to synchronize them to a release date. I think this is inherent to the way PostgreSQL is developed: Tom has previously compared PostgreSQL release scheduling to herding cats :-) As long as much of the work on the project is done by volunteers in their spare time, ISTM that coordinating everyone toward a single release date is going to be difficult, if not impossible. The length of the release cycle doesn't really effect this, IMHO. Linux, too, is done largely by volunteers in their spare time. Yet Linux kernel releases are much more frequent than PostgreSQL releases. One difference is that the Linux community makes a distinction between development releases and stable releases. The amount of time between stable releases is probably about the same as it is for PostgreSQL. The difference is that the *only* releases PostgreSQL makes are stable releases (or release candidates, when a stable release is close). That's something we might want to re-think. -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Release cycle length
Matthew T. O'Connor wrote: I agree with Peter's other comment, that the longer the development cycle, the longer the beta / bug shakeout period, perhaps a shorter dev cycle would yield a shorter beta period, but perhaps it would also result in a less solid release. Perhaps. Perhaps not. The fewer the changes, the less complexity you have to manage. But it would certainly result in a smaller set of feature changes per release. Some people might regard that as a good thing. The advantage to doing more frequent releases is that new features end up with more real-world testing within a given block of time, on average, because a lot more people pick up the releases than the CVS snapshots or even release candidates.. -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Release cycle length
That said, I'm not really sure how we can make better use of the beta period. One obvious improvement would be making the beta announcements more visible: the obscurity of the beta process on www.postgresql.org for 7.4 was pretty ridiculous. Does anyone else have a suggestion on what we can do to produce a more reliable .0 release in less time? I can think of a few things. 1. Try to encourage list members to actually test stuff. For example, I decided to find stuff that might be broken. So I checked the tutorial scripts (no-one ever looks at them) and found heaps of bugs. I thought about some new features and tried to break them. I also tend to find bugs by coding phpPgAdmin and delving into the nitty gritty of stuff. Maybe we could actually ask for people for the 'beta team'. Then, once we have volunteers, they are each assigned a set of features to test by the 'testing co-ordinator' (a new core position, say?) What you are asked to test depends on your skill, say. eg. Someone who just knows how to use postgres could test my upcoming COMMENT ON patch. (It's best if I myself do not test it) Someone with more skill with a debugger can be asked to test unique hash indexes by playing with concurrency, etc. The test co-ordinator could also manage the testing of new features as they are committed to save time later. The co-ordinator should also maintain a list of what features have been committed, which have been code reviewed (what Tom usually does) and which have been tested. Of course, I'm not talking about exhaustive testing here, just better and more organised that what we currently have. Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Release cycle length
Neil Conway writes: That said, I'm not really sure how we can make better use of the beta period. One obvious improvement would be making the beta announcements more visible: the obscurity of the beta process on www.postgresql.org for 7.4 was pretty ridiculous. Does anyone else have a suggestion on what we can do to produce a more reliable .0 release in less time? Here are a couple of ideas: 0. As you say, make it known to the public. Have people test their in-development applications using a beta. 1. Start platform testing on day 1 of beta. Last minute fixes for AIX or UnixWare are really becoming old jokes. 2. Have a complete account of the changes available at the start of beta, so people know what to test. 3. Use a bug-tracking system so that open items are known early and by everyone. 4. Have a schedule. Not We're looking at a release early in the later part of this year., but dates for steps such as feature freeze then, proposals for open issues fielded then, string freeze then, release candiate then. 5. If need be, have a release management team that manages 0-4. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Release cycle length
On Mon, 17 Nov 2003, Neil Conway wrote: That said, I'm not really sure how we can make better use of the beta period. One obvious improvement would be making the beta announcements more visible: the obscurity of the beta process on www.postgresql.org for 7.4 was pretty ridiculous. Does anyone else have a suggestion on what we can do to produce a more reliable .0 release in less time? Agreed ... here's a thought ... take the download page and break it into two pages: page 1: broken down into dev vs stable versions, including the date of release ... page 2: when you click on the version you want to download, it brings you to a subpage that is what the main page currently is (with all the flags and such) but instead of just sending ppl to the ftp site itself, actually have the link go to the directory that contains that version on the mirror site ... that first page of the download could contain descriptoins of the variosu releases, and state of releases? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Release cycle length
eg. Someone who just knows how to use postgres could test my upcoming COMMENT ON patch. (It's best if I myself do not test it) Someone with more skill with a debugger can be asked to test unique hash indexes by playing with concurrency, etc. I forgot to mention that people who just have large, complex production databases and test servers at their disposal should be given the task of: 1. Dumping their old version database 2. Loading that into the dev version of postgres 3. Dumping that using dev pg_dump 4. Loading that dump back in 5. Dumping it again 6. Diffing 3 and 5 Chris ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Release cycle length
--On Tuesday, November 18, 2003 04:43:12 +0100 Peter Eisentraut [EMAIL PROTECTED] wrote: Neil Conway writes: That said, I'm not really sure how we can make better use of the beta period. One obvious improvement would be making the beta announcements more visible: the obscurity of the beta process on www.postgresql.org for 7.4 was pretty ridiculous. Does anyone else have a suggestion on what we can do to produce a more reliable .0 release in less time? Here are a couple of ideas: 0. As you say, make it known to the public. Have people test their in-development applications using a beta. 1. Start platform testing on day 1 of beta. Last minute fixes for AIX or UnixWare are really becoming old jokes. The only reason we had last minute stuff for UnixWare this time was the timing of PG's release and the UP3 release from SCO. I try to test stuff fairly frequently, and this time I didn't know when, exactly, SCO would make the release of the updated compiler. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] Release cycle length
On Tue, 18 Nov 2003, Peter Eisentraut wrote: 0. As you say, make it known to the public. Have people test their in-development applications using a beta. and how do you propose we do that? I think this is the hard part ... other then the first beta, I post a note out to -announce and -general that the beta's have been tag'd and bundled for download ... I know Sean does up a 'devel' port for FreeBSD, but I don't believe any of the RPM/deb maintainers do anything until the final release ... 1. Start platform testing on day 1 of beta. Last minute fixes for AIX or UnixWare are really becoming old jokes. then each beta will have to be re-certified for that beta, up until release ... doable, but I don't think you'll find many that will bother until we are close to release ... 2. Have a complete account of the changes available at the start of beta, so people know what to test. Bruce, when do you do your initial HISTORY file? Something to move to the start of beta, if not? 3. Use a bug-tracking system so that open items are known early and by everyone. Waiting to see anyone decide on which one to use ... willing to spend the time working to get it online ... 4. Have a schedule. Not We're looking at a release early in the later part of this year., but dates for steps such as feature freeze then, proposals for open issues fielded then, string freeze then, release candiate then. We try that every release ... 5. If need be, have a release management team that manages 0-4. Core does that, but we just don't feel that being totally rigid is (or has ever been) a requirement ... but, if you can provide suggestions on points 0 and 3, we're all ears ... ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Release cycle length
On Mon, 17 Nov 2003, Larry Rosenman wrote: I try to test stuff fairly frequently, and this time I didn't know when, exactly, SCO would make the release of the updated compiler. And there was no way you could predict that your contact there would take off on holidays either :( ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Release cycle length
Marc G. Fournier [EMAIL PROTECTED] writes: On Tue, 18 Nov 2003, Peter Eisentraut wrote: 0. As you say, make it known to the public. Have people test their in-development applications using a beta. and how do you propose we do that? I think this is the hard part (1) Make the beta more obvious on the website, as we've already discussed (2) Make a freshmeat.net release announcement for _each_ beta, RC, and of course the final release (we totally missed this during 7.4). There are probably other software release announcement sites we could inform. (3) Is it worth trying to get some technical press coverage for the start of the beta process? I don't mean on PHB-oriented sites like ComputerWorld or ZdNet where we need to do the work of getting a press release prepared, but OSNews or Slashdot just need a link to the release notes and the source tarballs. Any other suggestions? Perhaps we could add a list of this sort to src/tools/RELEASE_CHANGES? -Neil ---(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 cycle length
On Tue, 18 Nov 2003, Neil Conway wrote: Marc G. Fournier [EMAIL PROTECTED] writes: On Tue, 18 Nov 2003, Peter Eisentraut wrote: 0. As you say, make it known to the public. Have people test their in-development applications using a beta. and how do you propose we do that? I think this is the hard part (1) Make the beta more obvious on the website, as we've already discussed (2) Make a freshmeat.net release announcement for _each_ beta, RC, and of course the final release (we totally missed this during 7.4). There are probably other software release announcement sites we could inform. Damn, I keep forgetting freshmeat.net altogether ... will get that one during the day tomorrow ... (3) Is it worth trying to get some technical press coverage for the start of the beta process? I don't mean on PHB-oriented sites like ComputerWorld or ZdNet where we need to do the work of getting a press release prepared, but OSNews or Slashdot just need a link to the release notes and the source tarballs. I think so ... just a heads up to tell ppl that we are heading into the final stretch for the next release, and testing would be 'a good thing' ... ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
