Thread: 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 ;)
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
> > 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, Pennsylvania19026
> > 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
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
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
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
==========================================================================
> 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, Pennsylvania19026
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
> > 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
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
> 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, Pennsylvania19026