> Are you going to generate HISTORY from (sgml) for this release?  If so, I
> will skip updating that.

Yes. So, I'm going to be out of town from this evening through the
holiday weekend. And I would need a few days (4?; could shrink it a
bit by taking a day from work) to prepare postscript hardcopy for a
release.

Are we on track to release June 1? If so, I'd like to derail it by a
few days to get the hardcopy docs prepared. If not, I won't need to
take the fall for asking for a slip ;)

An alternative which I would support but am not yet as satisfied with
would be to decouple the hardcopy docs from the release package. Then
I could release the hardcopy a few days after the actual release.

This alternative has the attractive feature that I don't need to get
final updates two weeks in advance of a release to start prepping the
hardcopy. Especially since I *never* manage to get those updates from
everyone that early. html and text files like INSTALL would ship with
the first release, since those are either automatic (html) or easy (~5
minutes each for INSTALL or HISTORY).

Comments?

                      - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Thu, 27 May 1999 16:03:22 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Release date and docs
> > Are you going to generate HISTORY from (sgml) for this release?  If so, I
> > will skip updating that.
> 
> Yes. So, I'm going to be out of town from this evening through the
> holiday weekend. And I would need a few days (4?; could shrink it a
> bit by taking a day from work) to prepare postscript hardcopy for a
> release.
> 
> Are we on track to release June 1? If so, I'd like to derail it by a
> few days to get the hardcopy docs prepared. If not, I won't need to
> take the fall for asking for a slip ;)

No one has requested any kind of slip from June 1.  I may if we can't
get these final items done on the open list.  My major item is to fix
the psql \h, man pages, and docs for the new locking parameters from
Vadim.  That will have to be done before the release, and I haven't done
them yet.  We also need regression tests from numeric.  I would say we
should target June 4 or June 7 for the release, depending on whether we
need the weekend.  We are certainly in good shape for this release,
though.


> 
> An alternative which I would support but am not yet as satisfied with
> would be to decouple the hardcopy docs from the release package. Then
> I could release the hardcopy a few days after the actual release.

No, no reason to do that, and once we release, we will be very busy
fielding problem reports, so it doesn't buy us anything to decouple
them.

> 
> This alternative has the attractive feature that I don't need to get
> final updates two weeks in advance of a release to start prepping the
> hardcopy. Especially since I *never* manage to get those updates from
> everyone that early. html and text files like INSTALL would ship with
> the first release, since those are either automatic (html) or easy (~5
> minutes each for INSTALL or HISTORY).

Again, let's not decouple them.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

Thu, 27 May 1999 12:10:50 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: Release date and docs
> > Are we on track to release June 1? If so, I'd like to derail it by a
> > few days to get the hardcopy docs prepared. If not, I won't need to
> > take the fall for asking for a slip ;)
> No one has requested any kind of slip from June 1.  I may if we can't
> get these final items done on the open list.  My major item is to fix
> the psql \h, man pages, and docs for the new locking parameters from
> Vadim.  That will have to be done before the release, and I haven't done
> them yet.  We also need regression tests from numeric.  I would say we
> should target June 4 or June 7 for the release, depending on whether we
> need the weekend.  We are certainly in good shape for this release,
> though.

OK. I've just sent some updates for your ToDo list. The regression
test stuff is coming from Jan afaik, but someone else can do it if he
can't.

                  - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Thu, 27 May 1999 16:35:43 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: Release date and docs
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> An alternative which I would support but am not yet as satisfied with
> would be to decouple the hardcopy docs from the release package.

Totally apart from any schedule considerations, I think it would be good
if the derived forms of the docs (the .ps files and tarred .html files
in pgsql/doc) were decoupled from the source distribution.  In
particular, remove those files from the CVS archives and distribute
them as a separate tarball rather than as part of the source tarballs.

This'd be good on general principles (derived files should not be in
CVS) and it'd also reduce the size of snapshot tarballs by a couple of
meg, which is a useful savings.  Since the derived docs are always a
version behind during the runup to a new release, I don't see much
value in forcing people to download 'em.

A further improvement, which oughta be pretty easy if the doc prep tools
are installed at hub.org, is to produce a nightly tarball of the derived
docs *generated from the currently checked-in sources*.  As someone who
doesn't have the doc prep tools installed locally, I know I would find
that very useful.  Right now, I have the choice of looking at 6.4.* docs
or raw SGML :-(.

If you don't want to change our distribution practices to the extent
of having separate source-code and doc tarfiles, then it'd at least be
a good idea to regenerate the derived docs as part of the nightly
snapshot-building run, so that the snapshots contain up-to-date derived
files rather than historical artifacts...

			regards, tom lane

Thu, 27 May 1999 13:31:35 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Release date and docs 
On Thu, 27 May 1999, Bruce Momjian wrote:

> > > Are you going to generate HISTORY from (sgml) for this release?  If so, I
> > > will skip updating that.
> > 
> > Yes. So, I'm going to be out of town from this evening through the
> > holiday weekend. And I would need a few days (4?; could shrink it a
> > bit by taking a day from work) to prepare postscript hardcopy for a
> > release.
> > 
> > Are we on track to release June 1? If so, I'd like to derail it by a
> > few days to get the hardcopy docs prepared. If not, I won't need to
> > take the fall for asking for a slip ;)
> 
> No one has requested any kind of slip from June 1.  I may if we can't
> get these final items done on the open list.  My major item is to fix
> the psql \h, man pages, and docs for the new locking parameters from
> Vadim.  That will have to be done before the release, and I haven't done
> them yet.  We also need regression tests from numeric.  I would say we
> should target June 4 or June 7 for the release, depending on whether we
> need the weekend.  We are certainly in good shape for this release,
> though.

Let's make it June 7th...I prefer a Monday release to a Friday one, and if
Thomas needs a little more time for the docs, and you have a couple of
things you want dealt with, take the extra couple of days...

Let's lock her down for June 7th though...Vince?

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


Fri, 28 May 1999 09:58:47 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: Release date and docs
On Fri, 28 May 1999, The Hermit Hacker wrote:

> Let's lock her down for June 7th though...Vince?

Announcement on web page?   I think I have all code and docs turned in,
I didn't miss something did I?

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
       # include <std/disclaimers.h>                   TEAM-OS2
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Fri, 28 May 1999 12:51:52 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] Re: Release date and docs
> On Fri, 28 May 1999, The Hermit Hacker wrote:
> 
> > Let's lock her down for June 7th though...Vince?
> 
> Announcement on web page?   I think I have all code and docs turned in,
> I didn't miss something did I?
> 

Yes, let's get something on the web page.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

Fri, 28 May 1999 12:52:18 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: Release date and docs
On Fri, 28 May 1999, Vince Vielhaber wrote:

> On Fri, 28 May 1999, The Hermit Hacker wrote:
> 
> > Let's lock her down for June 7th though...Vince?
> 
> Announcement on web page?   I think I have all code and docs turned in,
> I didn't miss something did I?

Just announcement on web page :)

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


Fri, 28 May 1999 13:56:43 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: Release date and docs
> > An alternative which I would support but am not yet as satisfied with
> > would be to decouple the hardcopy docs from the release package.
> Totally apart from any schedule considerations, I think it would be good
> if the derived forms of the docs (the .ps files and tarred .html files
> in pgsql/doc) were decoupled from the source distribution.  In
> particular, remove those files from the CVS archives and distribute
> them as a separate tarball rather than as part of the source tarballs.
> This'd be good on general principles (derived files should not be in
> CVS) and it'd also reduce the size of snapshot tarballs by a couple of
> meg, which is a useful savings.  Since the derived docs are always a
> version behind during the runup to a new release, I don't see much
> value in forcing people to download 'em.

These are good points.

> A further improvement, which oughta be pretty easy if the doc prep tools
> are installed at hub.org, is to produce a nightly tarball of the derived
> docs *generated from the currently checked-in sources*.  As someone who
> doesn't have the doc prep tools installed locally, I know I would find
> that very useful.  Right now, I have the choice of looking at 6.4.* docs
> or raw SGML :-(.

Really? We've been doing exactly as you suggest for several months now
:)

Look in ftp://postgresql.org/pub/doc/*.tar.gz for snapshot html, and
the web site docs are just untarred versions of the same thing. These
are all generated on a nightly basis directly from the CVS tree. We
should probably split those off into a developer's area rather than
have those be the *only* copy of web site docs, but it was a start.

Also, on hub.org ~thomas/CURRENT/docbuild is the script for the
nightly cron job, and my tree is set up to allow "committers" to use
it. If you use it from my tree, be sure to have your umask set to "2"
to allow group mods.

It's pretty nice having this run daily, because I get the cron log of
the run and can see when something new breaks the build from sgml.

> If you don't want to change our distribution practices to the extent
> of having separate source-code and doc tarfiles, then it'd at least be
> a good idea to regenerate the derived docs as part of the nightly
> snapshot-building run, so that the snapshots contain up-to-date derived
> files rather than historical artifacts...

Good idea, but we don't want to do CVS updates on those big tar files.

What do other folks think??

                      - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Tue, 01 Jun 1999 14:23:51 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Release date and docs
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> Really? We've been doing exactly as you suggest for several months now
> :)

> Look in ftp://postgresql.org/pub/doc/*.tar.gz for snapshot html, and
> the web site docs are just untarred versions of the same thing. These
> are all generated on a nightly basis directly from the CVS tree.

Cool, I didn't know about that.  Thanks!

			regards, tom lane

Tue, 01 Jun 1999 10:39:03 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Release date and docs 
> It's pretty nice having this run daily, because I get the cron log of
> the run and can see when something new breaks the build from sgml.
> 
> > If you don't want to change our distribution practices to the extent
> > of having separate source-code and doc tarfiles, then it'd at least be
> > a good idea to regenerate the derived docs as part of the nightly
> > snapshot-building run, so that the snapshots contain up-to-date derived
> > files rather than historical artifacts...
> 
> Good idea, but we don't want to do CVS updates on those big tar files.
> 
> What do other folks think??

I like the current setup.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

Tue, 1 Jun 1999 10:46:32 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Release date and docs