
Okay, since I haven't gotten word back on where to find the docs for v7.1,
it still contains those for v7.0, but I just put up beta1 tarballs in the
/pub/dev directory ... can someone take a look at these before we announce
them to make sure they look okay?


Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Thu, 7 Dec 2000 15:48:25 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
v7.1 beta 1 ...packaged, finally ...
On Thursday 07 December 2000 16:48, The Hermit Hacker wrote:
> Okay, since I haven't gotten word back on where to find the docs for v7.1,
> it still contains those for v7.0, but I just put up beta1 tarballs in the
> /pub/dev directory ... can someone take a look at these before we announce
> them to make sure they look okay?

I'm in the process of downloading. What would be the diff between the beta1 
and the snapshot?

Saludos... :-)

-- 
"And I'm happy, because you make me feel good, about me." - Melvin Udall
-----------------------------------------------------------------
Mart���n Marqu���s			email: 	martin@math.unl.edu.ar
Santa Fe - Argentina		http://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-----------------------------------------------------------------

Thu, 7 Dec 2000 17:34:54 -0300
"Martin A. Marques" <martin@math.unl.edu.ar>
Re: v7.1 beta 1 ...packaged, finally ...
The Hermit Hacker <scrappy@hub.org> writes:
> it still contains those for v7.0, but I just put up beta1 tarballs in the
> /pub/dev directory ... can someone take a look at these before we announce
> them to make sure they look okay?

The tarballs match what I have locally ... ship 'em ...

			regards, tom lane

Thu, 07 Dec 2000 15:51:23 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: v7.1 beta 1 ...packaged, finally ... 
The Hermit Hacker writes:

> Okay, since I haven't gotten word back on where to find the docs for v7.1,

/home/projects/pgsql/ftp/www/html/devel-corner/docs

Ideally (IMHO) we'd build the documentation right in place when making the
distribution tarball, i.e., broken docs, no release.  I'm not sure how to
usefully extrapolate that to the snapshot builds, though.

Another thing we should think about is to not tar.gz the documentation
files.  That way we could create useful incremental diffs between releases
later on.  Any comments here?

> it still contains those for v7.0, but I just put up beta1 tarballs in the
> /pub/dev directory ... can someone take a look at these before we announce
> them to make sure they look okay?

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Thu, 7 Dec 2000 22:35:11 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: v7.1 beta 1 ...packaged, finally ...
Peter Eisentraut <peter_e@gmx.net> writes:
> Another thing we should think about is to not tar.gz the documentation
> files.  That way we could create useful incremental diffs between releases
> later on.  Any comments here?

I've never figured out why we do that.  Since the thing is going to be
inside a tarball anyway, there's no possible savings from distributing
the built doco that way, rather than as ordinary files.

			regards, tom lane

Thu, 07 Dec 2000 16:43:59 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: v7.1 beta 1 ...packaged, finally ... 
On Thursday 07 December 2000 18:35, Peter Eisentraut wrote:
>
> Ideally (IMHO) we'd build the documentation right in place when making the
> distribution tarball, i.e., broken docs, no release.  I'm not sure how to
> usefully extrapolate that to the snapshot builds, though.
>
> Another thing we should think about is to not tar.gz the documentation
> files.  That way we could create useful incremental diffs between releases
> later on.  Any comments here?

If you dont't tar.gz the docs, what should the downladable format be? CVS?
I think CVS would be great.


-- 
"And I'm happy, because you make me feel good, about me." - Melvin Udall
-----------------------------------------------------------------
Mart���n Marqu���s			email: 	martin@math.unl.edu.ar
Santa Fe - Argentina		http://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-----------------------------------------------------------------

Thu, 7 Dec 2000 19:22:55 -0300
"Martin A. Marques" <martin@math.unl.edu.ar>
Re: v7.1 beta 1 ...packaged, finally ...
On Thu, 7 Dec 2000, Martin A. Marques wrote:

> On Thursday 07 December 2000 16:48, The Hermit Hacker wrote:
> > Okay, since I haven't gotten word back on where to find the docs for v7.1,
> > it still contains those for v7.0, but I just put up beta1 tarballs in the
> > /pub/dev directory ... can someone take a look at these before we announce
> > them to make sure they look okay?
> 
> I'm in the process of downloading. What would be the diff between the beta1 
> and the snapshot?

None for today ... snapshot's are build daily, beta1 right now is "a
release candidate, if nobody reports any problems, we release what is
packaged" ... we usually wait for a two week period or so after each beta
is released for bug reporst before saying "its clean" ... if nobody
changes the code in CVS in two weeks, beta1 goes out as v7.1 ... if we
release a beta2, its two weeks from that, and so on ...



Thu, 7 Dec 2000 19:17:20 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: v7.1 beta 1 ...packaged, finally ...

I just recently heard from Julia Case, who is willing to work on
maintaining the ODBC drivers after Xmas ... for those that don't know the
name, she was pretty much the original ODBC developer/maintainer, until
work overwhelmed her ...

On Thu, 7 Dec 2000, Joel Burton wrote:

> The official ODBC driver from pg7.0.x doesn't work w/7.1 (b/c of the 
> changes in the system catalogs, IIRC).
> 
> The CVS 7.1devel code works and builds easily, but  I suspect 99% 
> of the beta testers won't have Visual C++ or won't be able to 
> compile the driver. Is there an official driver-compiler-person that 
> could package this up for 7.1beta?
> 
> (I know that a binary driver isn't part of the beta per se, and that 
> it's not *unreleasable* to think that everyone could compile their 
> own, but I bought VC++ just to compile this driver, and would hate 
> to see M$ get richer for even more people. Also, I doubt we'd want 
> to impugn the perceived quality of 7.1beta b/c people don't 
> understand that its just the ODBC drivers that out-of-date.)
>  
> If there's no one official tasked w/this, I'd be happy to submit my 
> compiled version, at http://www.scw.org/pgaccess.
> 
> 
> --
> Joel Burton, Director of Information Systems -*- jburton@scw.org
> Support Center of Washington (www.scw.org)
> 

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 



Thu, 7 Dec 2000 20:40:05 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] v7.1 beta 1 (ODBC driver?)
The official ODBC driver from pg7.0.x doesn't work w/7.1 (b/c of the 
changes in the system catalogs, IIRC).

The CVS 7.1devel code works and builds easily, but  I suspect 99% 
of the beta testers won't have Visual C++ or won't be able to 
compile the driver. Is there an official driver-compiler-person that 
could package this up for 7.1beta?

(I know that a binary driver isn't part of the beta per se, and that 
it's not *unreleasable* to think that everyone could compile their 
own, but I bought VC++ just to compile this driver, and would hate 
to see M$ get richer for even more people. Also, I doubt we'd want 
to impugn the perceived quality of 7.1beta b/c people don't 
understand that its just the ODBC drivers that out-of-date.)
 
If there's no one official tasked w/this, I'd be happy to submit my 
compiled version, at http://www.scw.org/pgaccess.


--
Joel Burton, Director of Information Systems -*- jburton@scw.org
Support Center of Washington (www.scw.org)

Thu, 7 Dec 2000 18:15:21 -0800
"Joel Burton" <jburton@scw.org>
Re: v7.1 beta 1 (ODBC driver?)
> > Another thing we should think about is to not tar.gz the documentation
> > files.  That way we could create useful incremental diffs between releases
> > later on.  Any comments here?
> I've never figured out why we do that.

Well...

> Since the thing is going to be
> inside a tarball anyway, there's no possible savings from distributing
> the built doco that way, rather than as ordinary files.

A couple of reasons, historically:

1) I was building docs locally, and moving them across to postgresql.org
over a modem. It wasn't for another year (?) before postgresql.org could
build them locally.

2) The first html docs were available before a release, and they needed
to be distributed.

3) We put the docs into cvs, but the jade/docbook output did not have
predictable file names. So each release would require wiping the output
docs and somehow guessing which files were obsolete and which were new.

4) We would have to install these individual files, and we didn't have a
technique for installing docs. Untarring seemed compatible with (2) and
(3).

Anyway, since we no longer put the docs tarball into cvs, then we could
rethink the techniques. Peter, you seem to have done enough work on this
to have an opinion, so what exactly would you prefer for packaging? I
recall that an unpacked tree was the suggestion??

I think that *requiring* that the html docs be built in place to effect
a release is an extra toolset burden that we should not accept. The fact
that the docs tools work well on postgresql.org as well as on other
machines is something to be enjoyed, not put into the critical path ;)

                       - Thomas

Fri, 08 Dec 2000 04:36:26 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: v7.1 beta 1 ...packaged, finally ...
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> [ various good reasons ]

> 3) We put the docs into cvs, but the jade/docbook output did not have
> predictable file names. So each release would require wiping the output
> docs and somehow guessing which files were obsolete and which were new.

That's something that's annoyed me for a good while in a different
context, namely that URLs for particular pages of the docs on
postgresql.org aren't stable.  (Well, maybe they are?  but foo58342.htm
doesn't give one a warm feeling about it.  chap3sec7.htm would look
a lot better.)

Is there any prospect of making the output filenames more predictable?
Who should I annoy about it?

> I think that *requiring* that the html docs be built in place to effect
> a release is an extra toolset burden that we should not accept.

Agreed on that one...

			regards, tom lane

Fri, 08 Dec 2000 00:55:21 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: v7.1 beta 1 ...packaged, finally ... 
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> ... and find the *every* .htm file has a "good" name. Hmm. Is it the
> fact that someone went through and added an "id field" to every chapter
> and section header? Whoever it was, good job! It wasn't me, but whoever
> it was: good job :)

> Ah, a perusal of the cvs log shows that Peter E. is the culprit. Looks
> like it is a non-issue from here on.

Oh, is *that* what that was for?  Thanks, Peter!

			regards, tom lane

Fri, 08 Dec 2000 01:29:55 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: v7.1 beta 1 ...packaged, finally ... 
> Is there any prospect of making the output filenames more predictable?
> Who should I annoy about it?

Well, you could annoy me about it...

... and I would go to my local installation of the source tree...

... and build the docs to confirm that the *chapters* have good
predictable names...

... and find the *every* .htm file has a "good" name. Hmm. Is it the
fact that someone went through and added an "id field" to every chapter
and section header? Whoever it was, good job! It wasn't me, but whoever
it was: good job :)

Ah, a perusal of the cvs log shows that Peter E. is the culprit. Looks
like it is a non-issue from here on.

                     - Thomas

Fri, 08 Dec 2000 06:43:03 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: v7.1 beta 1 ...packaged, finally ...
Thomas Lockhart writes:

> [valid reasons why docs are shipped in tar.gz format]
>
> Anyway, since we no longer put the docs tarball into cvs, then we could
> rethink the techniques. Peter, you seem to have done enough work on this
> to have an opinion, so what exactly would you prefer for packaging? I
> recall that an unpacked tree was the suggestion??

Unpacked would be okay.

If somehow a single-file approach is preferred, another option would be to
put the html files in an 'ar' archive.  That might seem a bit unusual, but
since the metadata in 'ar' archives is printable we can make diffs of the
archive files (the ability to make diffs being to goal here).

> I think that *requiring* that the html docs be built in place to effect
> a release is an extra toolset burden that we should not accept. The fact
> that the docs tools work well on postgresql.org as well as on other
> machines is something to be enjoyed, not put into the critical path ;)

The problem is that there's a delay of several hours (at best) between
updates to the source code and the availability of the built docs.  If
Marc makes the release he'll go into configure.in and change the version
number, if he doesn't forget he'll also update version.sgml, but then
he'll have to twiddle his thumbs until the documentation gets rebuild to
reflect the version change.  If he doesn't the release will ship
documentation that says "PostgreSQL 7.1devel".

The alternative is that the change to version.sgml be made earlier (like
now), but then he may run the mk-release script and the documentation that
sits on the ftp server might be several days old because no one bothered
to check the docbuild.log for several days.

All in all it's a synchronization and communication problem, but it's a
real problem, as history shows.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Sun, 10 Dec 2000 19:41:21 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: v7.1 beta 1 ...packaged, finally ...
> All in all it's a synchronization and communication problem, but it's a
> real problem, as history shows.

There is nothing stopping Marc from running the docs generation
explicitly just before release. The group permissions in my docs build
area are set to allow this.

Also, since the hardcopy is usually frozen ~2 weeks before release, I
don't see a reason why the tags etc couldn't be set for the release at
that time.

                        - Thomas

Mon, 11 Dec 2000 07:44:54 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: v7.1 beta 1 ...packaged, finally ...
On Mon, 11 Dec 2000, Thomas Lockhart wrote:

> > All in all it's a synchronization and communication problem, but it's a
> > real problem, as history shows.
> 
> There is nothing stopping Marc from running the docs generation
> explicitly just before release. The group permissions in my docs build
> area are set to allow this.

I have no probs with that ... what command should I run to do this, and do
I need to be cd'd into a specific directory before I run it? 



Mon, 11 Dec 2000 10:00:38 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: v7.1 beta 1 ...packaged, finally ...
Thomas Lockhart writes:

> There is nothing stopping Marc from running the docs generation
> explicitly just before release. The group permissions in my docs build
> area are set to allow this.

That's kind of what I meant, only instead of "Marc running the docs
generation explicitly just before release" I imagined "the docs generation
being run automatically when Marc generates the release".  It's just one
detour less that way.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Mon, 11 Dec 2000 18:08:33 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: v7.1 beta 1 ...packaged, finally ...