Thread: v7.1 beta 1 ...packaged, finally ...
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
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 -----------------------------------------------------------------
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
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/
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
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 -----------------------------------------------------------------
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)
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 ...
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
> > 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
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
> 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
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
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/
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?
> 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
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/