beta3

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Are we doing beta3 soon? I thought we were going to do it yesterday,
though it seems like we have a few packaging problems to iron out first.

The packaging problems need to be solved before we can build a release
candidate --- but I don't see why they should hold up beta3. beta2 has
the same problems, so beta3 wouldn't be a regression.

I don't have any pending work that ought to go in beta3, but I think
Thomas is sitting on some datetime patches ... probably should wait
for him.

regards, tom lane

Tom Lane writes:

The packaging problems need to be solved before we can build a release
candidate --- but I don't see why they should hold up beta3. beta2 has
the same problems, so beta3 wouldn't be a regression.

Considering the history of how-do-we-get-the-docs-in-the-tarball problem,
I'd like to see at least one beta where this works before shipping a
release candidate. Otherwise I'll have no confidence at all that we're
not going to ship the final release with last year's docs and no man
pages.

--
Peter Eisentraut peter_e@gmx.net

Okay, how do we want to address/fix/test this?

On Sun, 18 Nov 2001, Peter Eisentraut wrote:

Marc G. Fournier writes:

Okay, how do we want to address/fix/test this?

Assuming that we don't want to make sweeping changes to the overall
procedure, I suggest this:

1. The postgres.tar.gz and man.tar.gz documentation tarballs required for
a release used to be at ftp://ftp.postgresql.org/pub/dev/doc/. The new
file system location of this directory needs to be determined.

2. Some postgres.tar.gz and man.tar.gz files need to be put there.

3. The currently commented out portion in the mk-release script needs
to be altered to pick up these files.

(I also suggest 'set -e' in this script so it doesn't ignore errors.)

4. The HTML-doc-build cron job needs to be reinstated on postgresql.org
and put its output file at the new location.

5. When I'm done with the new manpages I'll upload them to the
appropriate location.

I think the answer to #1 is /var/spool/ftp or something. For #2, use the
postgres.tar.gz files that Bruce currently builds, and use the old
man.tar.gz file from 7.1.

I suggest when #3 is done we can ship a beta3.

For #4, I don't know who wants to do it. If it's me then it might take a
few days. #5 is well under way. When #4 and #5 are done we can ship rc1
or beta4, depending on the other issues.

--
Peter Eisentraut peter_e@gmx.net

On Mon, 19 Nov 2001, Peter Eisentraut wrote:

Marc G. Fournier writes:

Okay, how do we want to address/fix/test this?

Assuming that we don't want to make sweeping changes to the overall
procedure, I suggest this:

1. The postgres.tar.gz and man.tar.gz documentation tarballs required for
a release used to be at ftp://ftp.postgresql.org/pub/dev/doc/. The new
file system location of this directory needs to be determined.

Should simply be ~ftp/pub/dev/doc

2. Some postgres.tar.gz and man.tar.gz files need to be put there.

3. The currently commented out portion in the mk-release script needs
to be altered to pick up these files.

(I also suggest 'set -e' in this script so it doesn't ignore errors.)

Okay, just added 'set -e', commented out, to the script ... actually, just
uncommented it, for, even without the docs, it probably shouldn't be
ignored, eh? :)

4. The HTML-doc-build cron job needs to be reinstated on
postgresql.org and put its output file at the new location.

5. When I'm done with the new manpages I'll upload them to the
appropriate location.

I think the answer to #1 is /var/spool/ftp or something. For #2, use the
postgres.tar.gz files that Bruce currently builds, and use the old
man.tar.gz file from 7.1.

I suggest when #3 is done we can ship a beta3.

Okay, will bundle up Beta3 in the morning then ...

For #4, I don't know who wants to do it. If it's me then it might
take a few days. #5 is well under way. When #4 and #5 are done we
can ship rc1 or beta4, depending on the other issues.

Would #4 be these, from thomas old cron jobs:

# Run at 3:05 local time (EST5EDT?) every day
5 3 * * * $HOME/CURRENT/docbuild |& tee $HOME/CURRENT/docbuild.log
# Twice a day during beta 2000-03-28
25 11 * * * $HOME/CURRENT/docbuild |& tee $HOME/CURRENT/docbuild.log

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Peter Eisentraut
Sent: Monday, 19 November 2001 10:40 PM
To: Marc G. Fournier
Cc: Tom Lane; Bruce Momjian; PostgreSQL-development; Thomas Lockhart
Subject: Re: [HACKERS] beta3

Marc G. Fournier writes:

Okay, how do we want to address/fix/test this?

Assuming that we don't want to make sweeping changes to the overall
procedure, I suggest this:

1. The postgres.tar.gz and man.tar.gz documentation tarballs required for
a release used to be at ftp://ftp.postgresql.org/pub/dev/doc/. The new
file system location of this directory needs to be determined.

2. Some postgres.tar.gz and man.tar.gz files need to be put there.

Just a thought: Doesn't everyone have bzip2 these days? Many large
projects come bz2-only even these days. Is there a good reason to stick
with the extra-large tar.gz format?

Chris

On Tue, 20 Nov 2001, Christopher Kings-Lynne wrote:

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Peter Eisentraut
Sent: Monday, 19 November 2001 10:40 PM
To: Marc G. Fournier
Cc: Tom Lane; Bruce Momjian; PostgreSQL-development; Thomas Lockhart
Subject: Re: [HACKERS] beta3

Marc G. Fournier writes:

Okay, how do we want to address/fix/test this?

Assuming that we don't want to make sweeping changes to the overall
procedure, I suggest this:

1. The postgres.tar.gz and man.tar.gz documentation tarballs required for
a release used to be at ftp://ftp.postgresql.org/pub/dev/doc/. The new
file system location of this directory needs to be determined.

2. Some postgres.tar.gz and man.tar.gz files need to be put there.

Just a thought: Doesn't everyone have bzip2 these days? Many large
projects come bz2-only even these days. Is there a good reason to stick
with the extra-large tar.gz format?

Cause not everyone has bzip2 ... Solaris comes with gzip, doesn't come
with bzip ... not sure how many other OS, but even FreeBSD requiresyou to
compile bzip from ports, it isn't part of hte operating system ...

Cause not everyone has bzip2 ... Solaris comes with gzip, doesn't come
with bzip ... not sure how many other OS, but even FreeBSD requiresyou to
compile bzip from ports, it isn't part of hte operating system ...

FreeBSD 4.4 has it as part of the OS...

For example, the entire KDE project is bz2, and people use it on Solaris.

But anyway, fair enough - I guess it's an extra step that would inhibit the
use of Postgres.

Chris

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cause not everyone has bzip2 ...

Why not have both, so the user can choose? Many other
things on the net do just that. That way, I can choose
bz2 for a quick download, or use gz if I am using an
inferior OS :)

While we're on the subject, how about digitally signing the
releases as well? An MD5 checksum is fine, but certainly
won't protect against trojans and other maliciousness that
a pgp signature could prevent.

Greg Sabino Mullane
greg@turnstep.com
PGP Key: 0x14964AC8 200111191132

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iQA/AwUBO/nc+7ybkGcUlkrIEQLBPgCeM6CXgV0W7WjJBwGhiVj6u8hjPJ8An3Os
fP8flAAcciNI6FfOPyXKsD1B
=00M7
-----END PGP SIGNATURE-----

On Lun 19 Nov 2001 22:49, you wrote:

On Tue, 20 Nov 2001, Christopher Kings-Lynne wrote:

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Peter
Eisentraut Sent: Monday, 19 November 2001 10:40 PM
To: Marc G. Fournier
Cc: Tom Lane; Bruce Momjian; PostgreSQL-development; Thomas Lockhart
Subject: Re: [HACKERS] beta3

Marc G. Fournier writes:

Okay, how do we want to address/fix/test this?

Assuming that we don't want to make sweeping changes to the overall
procedure, I suggest this:

1. The postgres.tar.gz and man.tar.gz documentation tarballs required
for a release used to be at ftp://ftp.postgresql.org/pub/dev/doc/. The
new file system location of this directory needs to be determined.

2. Some postgres.tar.gz and man.tar.gz files need to be put there.

Just a thought: Doesn't everyone have bzip2 these days? Many large
projects come bz2-only even these days. Is there a good reason to stick
with the extra-large tar.gz format?

Cause not everyone has bzip2 ... Solaris comes with gzip, doesn't come
with bzip ... not sure how many other OS, but even FreeBSD requiresyou to
compile bzip from ports, it isn't part of hte operating system ...

Go to www.sunfreeware.com and get bzip2 for Solaris.
I even recompiled the new tar with support for bzip2! :-)

Saludos... :-)

P.D.: bzip2 is slow, but you can get a real small package with it, even
though PostgreSQL isn't that big, if we compare it with KDE or Mozilla.

--
Porqu� usar una base de datos relacional cualquiera,
si pod�s usar PostgreSQL?
-----------------------------------------------------------------
Mart�n Marqu�s | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica
Universidad Nacional
del Litoral
-----------------------------------------------------------------

=?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar> writes:

P.D.: bzip2 is slow, but you can get a real small package with it, even
though PostgreSQL isn't that big, if we compare it with KDE or Mozilla.

As an experiment, I zipped my current PG source tree with both. (This
isn't an exact test of the distribution size, because I didn't bother
to get rid of the CVS control files, but it's pretty close.)

Original tar file: 37089280 bytes
gzip -9: 8183182 bytes
bzip2: 6762638 bytes

or slightly less than a 20% savings for bzip over gzip. That's useful,
but not exactly compelling. A comparison of unzip runtime also seems
relevant:

$ time gunzip pgsql.tar.gz

real 0m5.48s
user 0m4.46s
sys 0m0.62s

$ time bunzip2 pgsql.tar.bz2

real 0m27.77s
user 0m26.50s
sys 0m0.92s

If I'd downloaded this thing over a decent DSL or cable modem line,
bzip2 would actually be a net loss in total download + uncompress time.

<editorial>
The reason bzip is still an also-ran is that it's not enough better
than gzip to have persuaded people to switch over. My bet is that
bzip will always be an also-ran, and that gzip will remain the de
facto standard until something comes along that's really significantly
better, like a factor of 2 better. I've watched this sort of game
play out before, and I know you don't take over the world with a 20%
improvement over the existing standard. At least not without other
compelling reasons, like speed (oops) or patent freedom (no win there
either).
</editorial>

regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If I'd downloaded this thing over a decent DSL or cable modem
line, bzip2 would actually be a net loss in total
download + uncompress time.

I think the download time is a lot more important to people than
the uncompression time. A savings of nearly 1.5 Megs is
significant, no matter what type of line you are on. If we can
shave off 1.5M for a 56K user, why not?

My runtime tests were also different:

bzip -9: 8.959 real
bzip -1: 7.473 real
gzip -9: 1.491 real

That's not much of a difference, and (IMO) is more than offset
by the smaller download size. Bandwidth should be a more
important factor: after all, the next few steps (tar,
configure, make) are going to make the unzipping seem fast
in comparison. :)

I'm not advocating *replacing* gzip with bzip2, but I do think
we should make it an option. It should not be that much
trouble.

Digital signatures, on the other hand, are a lot more trouble
but are much more important than the gzip/bzip2 issue....

Greg Sabino Mullane
greg@turnstep.com
PGP Key: 0x14964AC8 200111201606

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iQA/AwUBO/rG+LybkGcUlkrIEQJO8wCdGlZgyQUTYwLUMTrSwcmmnUx0nlYAn37H
I6W1G8h+7jQIIiBTuHQeKQB7
=PtZi
-----END PGP SIGNATURE-----

"Greg Sabino Mullane" <greg@turnstep.com> writes:

If I'd downloaded this thing over a decent DSL or cable modem
line, bzip2 would actually be a net loss in total
download + uncompress time.

I think the download time is a lot more important to people than
the uncompression time. A savings of nearly 1.5 Megs is
significant, no matter what type of line you are on.

And for CD space (I'd love bzipped binaries), ftp space, etc (not only
for mirrors, but for distributions shipping postgresql and mirrors
thereeof.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

On Mar 20 Nov 2001 12:16, Tom Lane wrote:

As an experiment, I zipped my current PG source tree with both. (This
isn't an exact test of the distribution size, because I didn't bother
to get rid of the CVS control files, but it's pretty close.)

Original tar file: 37089280 bytes
gzip -9: 8183182 bytes
bzip2: 6762638 bytes

or slightly less than a 20% savings for bzip over gzip. That's useful,
but not exactly compelling. A comparison of unzip runtime also seems
relevant:

$ time gunzip pgsql.tar.gz

real 0m5.48s
user 0m4.46s
sys 0m0.62s

$ time bunzip2 pgsql.tar.bz2

real 0m27.77s
user 0m26.50s
sys 0m0.92s

If I'd downloaded this thing over a decent DSL or cable modem line,
bzip2 would actually be a net loss in total download + uncompress time.

That would be if I have a decent DSL or cable modem. We have a dedicated line
of 756 kb, but we also have 3000 users. Maybe postgreSQL isn't that big, but
Mozilla or KDE are, and waiting for la large download isn't what I recommend
for an internet experience. :-)

<editorial>
The reason bzip is still an also-ran is that it's not enough better
than gzip to have persuaded people to switch over. My bet is that
bzip will always be an also-ran, and that gzip will remain the de
facto standard until something comes along that's really significantly
better, like a factor of 2 better. I've watched this sort of game
play out before, and I know you don't take over the world with a 20%
improvement over the existing standard. At least not without other
compelling reasons, like speed (oops) or patent freedom (no win there
either).
</editorial>

I think it comes to what CPU I'm using. If I'm on an old Pentium, I may not
be happy seeing unbzip2 grabbing all my CPU, but if I'm on a last generation
PIV of, lets say 1000Mhz, I may not feel it.

Saludos... :-)

--
Porqu� usar una base de datos relacional cualquiera,
si pod�s usar PostgreSQL?
-----------------------------------------------------------------
Mart�n Marqu�s | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica
Universidad Nacional
del Litoral
-----------------------------------------------------------------

On 20 Nov 2001, Trond Eivind [iso-8859-1] Glomsr���d wrote:

"Greg Sabino Mullane" <greg@turnstep.com> writes:

If I'd downloaded this thing over a decent DSL or cable modem
line, bzip2 would actually be a net loss in total
download + uncompress time.

I think the download time is a lot more important to people than
the uncompression time. A savings of nearly 1.5 Megs is
significant, no matter what type of line you are on.

And for CD space (I'd love bzipped binaries), ftp space, etc (not only
for mirrors, but for distributions shipping postgresql and mirrors
thereeof.

Huh? You are advocating adding to the ftp space required? *raised
eyebrow*

Okay, tried today what you suggested, about set -e and all that ... take a
look at ~pgsql/bin/mk-beta, to see if maybe I missed something ... but,
trying to do the packaging, I'm getting an error about 'build.xml'?

/usr/bin/tar cf postgresql-opt-7.2b3.tar postgresql-7.2b3/src/backend/utils/mb postgresql-7.2b3/contrib/retep postgresql-7.2b3/build.xml postgresql-7.2b3/src/tools postgresql-7.2b3/src/corba postgresql-7.2b3/src/data postgresql-7.2b3/src/tutorial postgresql-7.2b3/src/bin/pgaccess postgresql-7.2b3/src/bin/pgtclsh postgresql-7.2b3/src/bin/pg_encoding postgresql-7.2b3/src/interfaces/odbc postgresql-7.2b3/src/interfaces/libpq++ postgresql-7.2b3/src/interfaces/libpgtcl postgresql-7.2b3/src/interfaces/perl5 postgresql-7.2b3/src/interfaces/python postgresql-7.2b3/src/interfaces/jdbc postgresql-7.2b3/src/pl/plperl postgresql-7.2b3/src/pl/tcl
/usr/bin/tar: can't add file postgresql-7.2b3/build.xml : No such file or directory
gmake: *** [postgresql-opt-7.2b3.tar] Error 1
gmake: *** Deleting file `postgresql-opt-7.2b3.tar'
%

Looking in the wrong directory?

%find . -name build.xml -print
./contrib/retep/build.xml
./src/interfaces/jdbc/build.xml
%

On Mon, 19 Nov 2001, Peter Eisentraut wrote:

Okay, tried today what you suggested, about set -e and all that ... take a
look at ~pgsql/bin/mk-beta, to see if maybe I missed something ... but,
trying to do the packaging, I'm getting an error about 'build.xml'?

/usr/bin/tar cf postgresql-opt-7.2b3.tar postgresql-7.2b3/src/backend/utils/mb postgresql-7.2b3/contrib/retep postgresql-7.2b3/build.xml postgresql-7.2b3/src/tools postgresql-7.2b3/src/corba postgresql-7.2b3/src/data postgresql-7.2b3/src/tutorial postgresql-7.2b3/src/bin/pgaccess postgresql-7.2b3/src/bin/pgtclsh postgresql-7.2b3/src/bin/pg_encoding postgresql-7.2b3/src/interfaces/odbc postgresql-7.2b3/src/interfaces/libpq++ postgresql-7.2b3/src/interfaces/libpgtcl postgresql-7.2b3/src/interfaces/perl5 postgresql-7.2b3/src/interfaces/python postgresql-7.2b3/src/interfaces/jdbc postgresql-7.2b3/src/pl/plperl postgresql-7.2b3/src/pl/tcl
/usr/bin/tar: can't add file postgresql-7.2b3/build.xml : No such file or directory
gmake: *** [postgresql-opt-7.2b3.tar] Error 1
gmake: *** Deleting file `postgresql-opt-7.2b3.tar'
%

Looking in the wrong directory?

%find . -name build.xml -print
./contrib/retep/build.xml
./src/interfaces/jdbc/build.xml
%

OK, patch applied. There was a space where there should have been a
slash.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Okay, tried today what you suggested, about set -e and all that ... take a
look at ~pgsql/bin/mk-beta, to see if maybe I missed something ... but,
trying to do the packaging, I'm getting an error about 'build.xml'?

/usr/bin/tar cf postgresql-opt-7.2b3.tar postgresql-7.2b3/src/backend/utils/mb postgresql-7.2b3/contrib/retep postgresql-7.2b3/build.xml postgresql-7.2b3/src/tools postgresql-7.2b3/src/corba postgresql-7.2b3/src/data postgresql-7.2b3/src/tutorial postgresql-7.2b3/src/bin/pgaccess postgresql-7.2b3/src/bin/pgtclsh postgresql-7.2b3/src/bin/pg_encoding postgresql-7.2b3/src/interfaces/odbc postgresql-7.2b3/src/interfaces/libpq++ postgresql-7.2b3/src/interfaces/libpgtcl postgresql-7.2b3/src/interfaces/perl5 postgresql-7.2b3/src/interfaces/python postgresql-7.2b3/src/interfaces/jdbc postgresql-7.2b3/src/pl/plperl postgresql-7.2b3/src/pl/tcl
/usr/bin/tar: can't add file postgresql-7.2b3/build.xml : No such file or directory
gmake: *** [postgresql-opt-7.2b3.tar] Error 1
gmake: *** Deleting file `postgresql-opt-7.2b3.tar'
%

Looking in the wrong directory?

%find . -name build.xml -print
./contrib/retep/build.xml
./src/interfaces/jdbc/build.xml
%

OK, patch applied. There was a space where there should have been a
slash.

OK, I found another problem:

gzip -f --best postgresql-base-7.2b3.tar
/usr/bin/tar cf postgresql-docs-7.2b3.tar
postgresql-7.2b3/doc/postgres.tar.gz postgresql-7.2b3/doc/src

^^^^^^^^^^^^^^^^^^^
postgresql-7.2b3/doc/TODO.detail postgresql-7.2b3/doc/internals.ps
/usr/bin/tar: can't add file postgresql-7.2b3/doc/postgres.tar.gz : No

^^^^^^^^^^^^^^^^^^^

such file or directory

The problem is this line in pgsql/GNUmakefile.in:

docs_files := doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps

Why is doc/postgres.tar.gz used. It normally is in doc/src, and why
only that doc tarball.

And again, there is that intenrals.ps file that doesn't really belong
there, I think.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Tue, Nov 20, 2001 at 10:16:57AM -0500, Tom Lane wrote:

Original tar file: 37089280 bytes
gzip -9: 8183182 bytes
bzip2: 6762638 bytes

maybe 1.420.544 it's not a big difference for you, but here in italy
there's still a lot of people using 33.6/55Kb telephone line modem.
so, this difference means, downloading at 3kb/s, seven minutes...
also:

a) cpu utilization has no cost... band cost a lot;
b) if i have to download 5 files, and i can avoid 1 MB of download for each
one...

thanks for your time,
andrea gelmini