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/
