Thread: Sigh, 7.3.6 rewrap not right
It looks to me like there are now *two* copies of the built manpages in
the 7.3.6 tarball, as well as some extraneous .md5 files:
Only in postgresql-7.3.6/doc: man-7.3.tar.gz
Only in postgresql-7.3.6/doc: man.tar.gz
Only in postgresql-7.3.6/doc: postgres.tar.gz
Only in postgresql-7.3.6: postgresql-base-7.3.6.tar.gz.md5
Only in postgresql-7.3.6: postgresql-docs-7.3.6.tar.gz.md5
Only in postgresql-7.3.6: postgresql-opt-7.3.6.tar.gz.md5
Only in postgresql-7.3.6: postgresql-test-7.3.6.tar.gz.md5
Not sure if it's worth trying again. The embedded md5 files are wrong
(they correspond to the Mar 1 wrap) and so could confuse people, and the
extra manpage set is adding 150K to the tarball size.
regards, tom lane
Okay, I've repackaged it, and temporarily put everything into /pub/source/v7.3.6_1 ... if ppl can confirm that I haven't somehow missed something again (I rm -rf'd the old build tree and re-cvs exported it, so it started clean), I'll move those files over to 7.3.6 ... On Thu, 4 Mar 2004, Tom Lane wrote: > It looks to me like there are now *two* copies of the built manpages in > the 7.3.6 tarball, as well as some extraneous .md5 files: > > Only in postgresql-7.3.6/doc: man-7.3.tar.gz > Only in postgresql-7.3.6/doc: man.tar.gz > Only in postgresql-7.3.6/doc: postgres.tar.gz > Only in postgresql-7.3.6: postgresql-base-7.3.6.tar.gz.md5 > Only in postgresql-7.3.6: postgresql-docs-7.3.6.tar.gz.md5 > Only in postgresql-7.3.6: postgresql-opt-7.3.6.tar.gz.md5 > Only in postgresql-7.3.6: postgresql-test-7.3.6.tar.gz.md5 > > Not sure if it's worth trying again. The embedded md5 files are wrong > (they correspond to the Mar 1 wrap) and so could confuse people, and the > extra manpage set is adding 150K to the tarball size. > > regards, tom lane > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> Okay, I've repackaged it, and temporarily put everything into
> /pub/source/v7.3.6_1 ... if ppl can confirm that I haven't somehow missed
> something again (I rm -rf'd the old build tree and re-cvs exported it, so
> it started clean), I'll move those files over to 7.3.6 ...
We are snakebit today, for certain :-(. The repackaged main tarball has
the right files, but there is something wrong with the built HTML docs
(doc/postgres.tar.gz). It is only 36K and seems to contain just
-rw-r--r-- pgsql/wheel 26163 2004-03-04 19:35 catalogs.gif
-rw-r--r-- pgsql/wheel 9485 2004-03-04 19:35 connections.gif
-rw-r--r-- pgsql/wheel 1151 2002-10-12 12:33 stylesheet.css
In the previous wrap it was 950K ...
regards, tom lane
k, trying again and trapping all the configure/make output, but other then putting the files in the _1 directory, the script i the same ... On Thu, 4 Mar 2004, Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> writes: > > Okay, I've repackaged it, and temporarily put everything into > > /pub/source/v7.3.6_1 ... if ppl can confirm that I haven't somehow missed > > something again (I rm -rf'd the old build tree and re-cvs exported it, so > > it started clean), I'll move those files over to 7.3.6 ... > > We are snakebit today, for certain :-(. The repackaged main tarball has > the right files, but there is something wrong with the built HTML docs > (doc/postgres.tar.gz). It is only 36K and seems to contain just > > -rw-r--r-- pgsql/wheel 26163 2004-03-04 19:35 catalogs.gif > -rw-r--r-- pgsql/wheel 9485 2004-03-04 19:35 connections.gif > -rw-r--r-- pgsql/wheel 1151 2002-10-12 12:33 stylesheet.css > > In the previous wrap it was 950K ... > > regards, tom lane > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
don't know what happen with that last one, but this one looks good: svr1# tar tvzpf postgresql-7.3.6.tar.gz | grep postgres.tar.gz -rw-r--r-- pgsql/wheel 954585 Mar 4 21:33 2004 postgresql-7.3.6/doc/postgres.tar.gz svr1# tar tvypf postgresql-7.3.6.tar.bz2 | grep postgres.tar.gz -rw-r--r-- pgsql/wheel 954585 Mar 4 21:33 2004 postgresql-7.3.6/doc/postgres.tar.gz On Thu, 4 Mar 2004, Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> writes: > > Okay, I've repackaged it, and temporarily put everything into > > /pub/source/v7.3.6_1 ... if ppl can confirm that I haven't somehow missed > > something again (I rm -rf'd the old build tree and re-cvs exported it, so > > it started clean), I'll move those files over to 7.3.6 ... > > We are snakebit today, for certain :-(. The repackaged main tarball has > the right files, but there is something wrong with the built HTML docs > (doc/postgres.tar.gz). It is only 36K and seems to contain just > > -rw-r--r-- pgsql/wheel 26163 2004-03-04 19:35 catalogs.gif > -rw-r--r-- pgsql/wheel 9485 2004-03-04 19:35 connections.gif > -rw-r--r-- pgsql/wheel 1151 2002-10-12 12:33 stylesheet.css > > In the previous wrap it was 950K ... > > regards, tom lane > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> don't know what happen with that last one, but this one looks good:
It looks good to me too, at least the main tar.gz seems correct.
regards, tom lane
'k, replaced with the good ones ... On Thu, 4 Mar 2004, Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> writes: > > don't know what happen with that last one, but this one looks good: > > It looks good to me too, at least the main tar.gz seems correct. > > regards, tom lane > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Thursday 04 March 2004 07:45 pm, Marc G. Fournier wrote: > Okay, I've repackaged it, and temporarily put everything into > /pub/source/v7.3.6_1 ... if ppl can confirm that I haven't somehow missed > something again (I rm -rf'd the old build tree and re-cvs exported it, so > it started clean), I'll move those files over to 7.3.6 ... Please, don't call it 7.3.6. Streamlining releases is terrible. 7.3.7 or 7.3.6.1 or SOMETHING other than 7.3.6, and just let 7.3.6 be a brown paper bag release (like 6.4.1 was). -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
Lamar Owen <lowen@pari.edu> writes:
> Please, don't call it 7.3.6. Streamlining releases is terrible. 7.3.7 or
> 7.3.6.1 or SOMETHING other than 7.3.6, and just let 7.3.6 be a brown paper
> bag release (like 6.4.1 was).
There were no code-change differences in this rewrap, so I see no real
need to change the version number.
The lesson I'd prefer to see us take away from this is that Marc needs
to automate his release wrapping process more. These sorta mistakes
shouldn't have happened in the first place ...
regards, tom lane
On Thursday 04 March 2004 10:28 pm, Tom Lane wrote: > There were no code-change differences in this rewrap, so I see no real > need to change the version number. > The lesson I'd prefer to see us take away from this is that Marc needs > to automate his release wrapping process more. These sorta mistakes > shouldn't have happened in the first place ... There are now multiple copies of 7.3.6 out there. How is a body to know which one to use? On RPMs, as you well now, SOP is to increment the release on any change, including a typo. This way there is no ambiguity. This is not the first time tarballs have been streamlined. I'm glad I hadn't built any RPMs yet. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
Lamar Owen wrote: > On Thursday 04 March 2004 10:28 pm, Tom Lane wrote: > > There were no code-change differences in this rewrap, so I see no real > > need to change the version number. > > > The lesson I'd prefer to see us take away from this is that Marc needs > > to automate his release wrapping process more. These sorta mistakes > > shouldn't have happened in the first place ... > > There are now multiple copies of 7.3.6 out there. How is a body to know which > one to use? On RPMs, as you well now, SOP is to increment the release on any > change, including a typo. This way there is no ambiguity. > > This is not the first time tarballs have been streamlined. I'm glad I hadn't > built any RPMs yet. My guess is that the packaging scripts are adjusted for new releases, but then don't work perfectly for older ones. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> On Thursday 04 March 2004 10:28 pm, Tom Lane wrote: > > There were no code-change differences in this rewrap, so I see no real > > need to change the version number. > > > The lesson I'd prefer to see us take away from this is that Marc needs > > to automate his release wrapping process more. These sorta mistakes > > shouldn't have happened in the first place ... > > There are now multiple copies of 7.3.6 out there. How is a body to know which > one to use? On RPMs, as you well now, SOP is to increment the release on any > change, including a typo. This way there is no ambiguity. > > This is not the first time tarballs have been streamlined. I'm glad I hadn't > built any RPMs yet. Sigh. I'm very uncomfortable with the existence of two versions of 7.3.6. Also the fact that I cannot get the "right" tar ball till it is copied to mirrors makes me uncomfortable too. -- Tatsuo Ishii
Tom Lane wrote: >Lamar Owen <lowen@pari.edu> writes: > > >>Please, don't call it 7.3.6. Streamlining releases is terrible. 7.3.7 or >>7.3.6.1 or SOMETHING other than 7.3.6, and just let 7.3.6 be a brown paper >>bag release (like 6.4.1 was). >> >> > >There were no code-change differences in this rewrap, so I see no real >need to change the version number. > >The lesson I'd prefer to see us take away from this is that Marc needs >to automate his release wrapping process more. These sorta mistakes >shouldn't have happened in the first place ... > > regards, tom lane > > How about in future, packaging it all up as a release candidate, (ie. 7.4.2-rc1) for a week or so before official final release, so package maintainers can build their scripts etc, and small problems like this ironed out. If anything needs to be corrected, it can be repackaged with a bumped rc number until it is determined that everything is fine. At which point the latest rc is renamed as the final release (ie. 7.4.2). Unless you already do this, and I've completely missed it somehow -- Mark Gibson <gibsonm |AT| cromwell |DOT| co |DOT| uk> Web Developer & Database Admin Cromwell Tools Ltd. Leicester, England.
On Friday 05 March 2004 09:50 am, Mark Gibson wrote: > How about in future, packaging it all up as a release candidate, > (ie. 7.4.2-rc1) for a week or so before official final release, We do this already for major versions. Maybe we should consider this for minors too. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
On Thursday 04 March 2004 7:28 pm, Tom Lane wrote: > Lamar Owen <lowen@pari.edu> writes: > > Please, don't call it 7.3.6. Streamlining releases is terrible. > > 7.3.7 or 7.3.6.1 or SOMETHING other than 7.3.6, and just let > > 7.3.6 be a brown paper bag release (like 6.4.1 was). > > There were no code-change differences in this rewrap, so I see no > real need to change the version number. I have to agree with Lamar et. al. The _code_ may not have changed but the "product" did and the version number should reflect that. This issue was discussed in InfoWorld a couple years back. I don't recall reading a single comment from someone who felt this practice benefitted them but there were plenty of tales of pain an frustration caused by even seemingly small changes between versions. Perhaps the fourth digit could represent non-code related updates such as documentation and packaging fixes. Cheers, Steve
Steve Crawford wrote: >>>Please, don't call it 7.3.6. Streamlining releases is terrible. >>>7.3.7 or 7.3.6.1 or SOMETHING other than 7.3.6, and just let >>>7.3.6 be a brown paper bag release (like 6.4.1 was). >> >>There were no code-change differences in this rewrap, so I see no >>real need to change the version number. > > I have to agree with Lamar et. al. The _code_ may not have changed but > the "product" did and the version number should reflect that. I second this. As someone has said, we should probably use the -rc mechanism in the future (changing the versioning from 7.3.6 into 7.3.6.1 has a greater chance of breaking things). Allow at least one week before the final -rc turns into final. The last -rc will be byte-to-byte identical with the final, we just rename it. *If* the final turns out to contain some stupid mistake, we'll just have to make 7.3.7... Once something is released, it should not change at all. -- dave