Обсуждение: stable snapshots...
Hi all! I just noticed that the tarballs in /pub/snapshot/stable/ on ftp.postgresql.org were still serving REL8_3_STABLE. I have now fixed the script generating them but I wonder if we should start naming the directory in a more sensible way (like /pub/snapshot/stable/8.3 and /pub/snapshot/stable/8.4,...) and also provide stable tarballs for more than just the latest version. comments? Stefan
On Mon, 13 Jul 2009, Stefan Kaltenbrunner wrote: > Hi all! > > I just noticed that the tarballs in /pub/snapshot/stable/ on > ftp.postgresql.org were still serving REL8_3_STABLE. > I have now fixed the script generating them but I wonder if we should start > naming the directory in a more sensible way (like /pub/snapshot/stable/8.3 > and /pub/snapshot/stable/8.4,...) and also provide stable tarballs for more > than just the latest version. > > comments? Not sure about the usefulness of the extra stable tarballs ... doesn't most of the back patching happen just as we are about to release the new versions? so the 'snapshot' will get a timestamp update, but no changes? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Marc G. Fournier wrote: > Not sure about the usefulness of the extra stable tarballs ... doesn't > most of the back patching happen just as we are about to release the new > versions? Not sure where you got that idea. There are plenty of times when somebody (mostly Tom) commits a bugfix and tells the reporter, stating that the release date of the new version is some undetermined point in the future. Not everyone is able to grab the patch from CVS and apply it; my guess is that most people simply wait for the next stable release. Those people would benefit from having the older stable branches, so here's a +1 to Stefan's idea. This is particularly useful now that we have more than a handful of supported back branches. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera <alvherre@commandprompt.com> writes: > Marc G. Fournier wrote: >> Not sure about the usefulness of the extra stable tarballs ... doesn't >> most of the back patching happen just as we are about to release the new >> versions? > Not sure where you got that idea. There are plenty of times when > somebody (mostly Tom) commits a bugfix and tells the reporter, stating > that the release date of the new version is some undetermined point in > the future. Not everyone is able to grab the patch from CVS and apply > it; my guess is that most people simply wait for the next stable > release. Those people would benefit from having the older stable > branches, so here's a +1 to Stefan's idea. Yeah. When we have fixed a bug but not yet released an official version with the fix, somebody who needs that bug fix has three choices:* manually apply the patch to a recent tarball;* pull fromCVS;* use a nightly snapshot. The first two cases require having extra tools like appropriate bison and flex versions (which right now is looking like a bigger deal than I would wish :-(). If we can build nightly snapshots for a release or two back without undue effort, I think it'd be a useful service. regards, tom lane
On Mon, 13 Jul 2009, Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: >> Marc G. Fournier wrote: >>> Not sure about the usefulness of the extra stable tarballs ... doesn't >>> most of the back patching happen just as we are about to release the new >>> versions? > >> Not sure where you got that idea. There are plenty of times when >> somebody (mostly Tom) commits a bugfix and tells the reporter, stating >> that the release date of the new version is some undetermined point in >> the future. Not everyone is able to grab the patch from CVS and apply >> it; my guess is that most people simply wait for the next stable >> release. Those people would benefit from having the older stable >> branches, so here's a +1 to Stefan's idea. > > Yeah. When we have fixed a bug but not yet released an official version > with the fix, somebody who needs that bug fix has three choices: > * manually apply the patch to a recent tarball; > * pull from CVS; > * use a nightly snapshot. > The first two cases require having extra tools like appropriate bison > and flex versions (which right now is looking like a bigger deal than > I would wish :-(). > > If we can build nightly snapshots for a release or two back without > undue effort, I think it'd be a useful service. Its not a problem to do it, I've just only noticed the 'bulk patches' close to releases ... How far do we want to go back? Straight to what is considered "supported"? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
"Marc G. Fournier" <scrappy@hub.org> writes: > On Mon, 13 Jul 2009, Tom Lane wrote: >> If we can build nightly snapshots for a release or two back without >> undue effort, I think it'd be a useful service. > How far do we want to go back? Straight to what is considered > "supported"? Hm, probably not all the way back to 7.4. The service would only be useful to people who are willing to build from a source tarball, and I bet not many of them are still running ancient releases. I was thinking that doing it for 8.3 and 8.2 would be about right at the moment. regards, tom lane
Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: >> Marc G. Fournier wrote: >>> Not sure about the usefulness of the extra stable tarballs ... doesn't >>> most of the back patching happen just as we are about to release the new >>> versions? > >> Not sure where you got that idea. There are plenty of times when >> somebody (mostly Tom) commits a bugfix and tells the reporter, stating >> that the release date of the new version is some undetermined point in >> the future. Not everyone is able to grab the patch from CVS and apply >> it; my guess is that most people simply wait for the next stable >> release. Those people would benefit from having the older stable >> branches, so here's a +1 to Stefan's idea. > > Yeah. When we have fixed a bug but not yet released an official version > with the fix, somebody who needs that bug fix has three choices: > * manually apply the patch to a recent tarball; > * pull from CVS; > * use a nightly snapshot. > The first two cases require having extra tools like appropriate bison > and flex versions (which right now is looking like a bigger deal than > I would wish :-(). yeah this is exactly what caused me to notice the original problem - somebody had an issue with 8.4.0 that is fixed in the stable branch already (the pl/perl locale issue) but was unable to use CVS and/or git for pulling the code down. We also should look into making this more automatic or at least document on the (www-) release TODO list. > If we can build nightly snapshots for a release or two back without > undue effort, I think it'd be a useful service. yeah - having say the last two or three releases available that way seems like a good thing to do. Stefan
Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: >> Marc G. Fournier wrote: >>> Not sure about the usefulness of the extra stable tarballs ... doesn't >>> most of the back patching happen just as we are about to release the new >>> versions? > >> Not sure where you got that idea. There are plenty of times when >> somebody (mostly Tom) commits a bugfix and tells the reporter, stating >> that the release date of the new version is some undetermined point in >> the future. Not everyone is able to grab the patch from CVS and apply >> it; my guess is that most people simply wait for the next stable >> release. Those people would benefit from having the older stable >> branches, so here's a +1 to Stefan's idea. > > Yeah. When we have fixed a bug but not yet released an official version > with the fix, somebody who needs that bug fix has three choices: > * manually apply the patch to a recent tarball; > * pull from CVS; > * use a nightly snapshot. > The first two cases require having extra tools like appropriate bison > and flex versions (which right now is looking like a bigger deal than > I would wish :-(). actually nagios just noticed that we managed to break our own -HEAD snapshot generation with this change as well... I have now fixed that script(and installed a more modern flex on developer.postgresql.org) as well but I think we have some more work to do in order to improve the robustness of those scripts... Stefan
On Wed, 15 Jul 2009, Stefan Kaltenbrunner wrote: > Tom Lane wrote: >> Alvaro Herrera <alvherre@commandprompt.com> writes: >>> Marc G. Fournier wrote: >>>> Not sure about the usefulness of the extra stable tarballs ... doesn't >>>> most of the back patching happen just as we are about to release the new >>>> versions? >> >>> Not sure where you got that idea. There are plenty of times when >>> somebody (mostly Tom) commits a bugfix and tells the reporter, stating >>> that the release date of the new version is some undetermined point in >>> the future. Not everyone is able to grab the patch from CVS and apply >>> it; my guess is that most people simply wait for the next stable >>> release. Those people would benefit from having the older stable >>> branches, so here's a +1 to Stefan's idea. >> >> Yeah. When we have fixed a bug but not yet released an official version >> with the fix, somebody who needs that bug fix has three choices: >> * manually apply the patch to a recent tarball; >> * pull from CVS; >> * use a nightly snapshot. >> The first two cases require having extra tools like appropriate bison >> and flex versions (which right now is looking like a bigger deal than >> I would wish :-(). > > actually nagios just noticed that we managed to break our own -HEAD snapshot > generation with this change as well... > I have now fixed that script(and installed a more modern flex on > developer.postgresql.org) as well but I think we have some more work to do in > order to improve the robustness of those scripts... Ummmmm ... you didn't break things, did you? Specifically as far as old builds are concerned?? There is a reason why we have an older flex on that machine :( Have you tested the new one you installed against all the other releases? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
"Marc G. Fournier" <scrappy@hub.org> writes: > Ummmmm ... you didn't break things, did you? Specifically as far as old > builds are concerned?? There is a reason why we have an older flex on > that machine :( It should be all right to update svr1 to something more recent. We know that flex 2.5.33 or .35 will work for all supported release branches; people (and the buildfarm in particular) have been testing that for a long time. regards, tom lane
Tom Lane wrote: > "Marc G. Fournier" <scrappy@hub.org> writes: >> Ummmmm ... you didn't break things, did you? Specifically as far as old >> builds are concerned?? There is a reason why we have an older flex on >> that machine :( > > It should be all right to update svr1 to something more recent. We know > that flex 2.5.33 or .35 will work for all supported release branches; > people (and the buildfarm in particular) have been testing that for a > long time. I didn't actually replace the old flex - I just installed a newer one from ports in addition to the still existing one from the OS. Only the snapshot generation script for -HEAD got modified to actually look for that specific flex version. Stefan
This is in effect now ... I have it generating 8.2, 8.3 and 8.4 daily ... let me know if we need any other releases ... BTW, should we be starting to do .zip source distributions now as well, for the Windows users? On Mon, 13 Jul 2009, Tom Lane wrote: > "Marc G. Fournier" <scrappy@hub.org> writes: >> On Mon, 13 Jul 2009, Tom Lane wrote: >>> If we can build nightly snapshots for a release or two back without >>> undue effort, I think it'd be a useful service. > >> How far do we want to go back? Straight to what is considered >> "supported"? > > Hm, probably not all the way back to 7.4. The service would only > be useful to people who are willing to build from a source tarball, > and I bet not many of them are still running ancient releases. > I was thinking that doing it for 8.3 and 8.2 would be about right > at the moment. > > regards, tom lane > ---- Marc G. Fournier Hub.Org Hosting Solutions S.A. scrappy@hub.org http://www.hub.org Yahoo:yscrappy Skype: hub.org ICQ:7615664 MSN:scrappy@hub.org
On Sun, Jul 26, 2009 at 03:42, Marc G. Fournier<scrappy@hub.org> wrote: > > > BTW, should we be starting to do .zip source distributions now as well, for > the Windows users? Nah, seems unnecessary. If you're trying to set up a postgresql build environment on windows, installing something like 7zip that can deal with .tar.gz or .tar.gz2 is the least of your problems. We need the .zip:s for people who just want the prebuilt binaries, but not for those who build from source. -- Magnus HaganderSelf: http://www.hagander.net/Work: http://www.redpill-linpro.com/