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: [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
