Re: [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE r ...

CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: petere(at)svr1(dot)postgresql(dot)org 03/12/21 17:36:34

Modified files:
doc/src/sgml : Tag: REL7_4_STABLE release.sgml

Log message:
Some refining of release notes. Markup is still broken by someone else,
so I cannot remake HISTORY.

Peter Eisentraut - PostgreSQL wrote:
> CVSROOT: /cvsroot
> Module name: pgsql-server
> Changes by: petere(at)svr1(dot)postgresql(dot)org 03/12/21 17:36:34
>
> Modified files:
> doc/src/sgml : Tag: REL7_4_STABLE release.sgml
>
> Log message:
> Some refining of release notes. Markup is still broken by someone else,
> so I cannot remake HISTORY.

I have regenerated HISTORY in 7.4.x and HEAD.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Are we going to regenerate the 7.4.1 tar ball?
--
Tatsuo Ishii

> Peter Eisentraut - PostgreSQL wrote:
> > CVSROOT: /cvsroot
> > Module name: pgsql-server
> > Changes by: petere(at)svr1(dot)postgresql(dot)org 03/12/21 17:36:34
> >
> > Modified files:
> > doc/src/sgml : Tag: REL7_4_STABLE release.sgml
> >
> > Log message:
> > Some refining of release notes. Markup is still broken by someone else,
> > so I cannot remake HISTORY.
>
> I have regenerated HISTORY in 7.4.x and HEAD.
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> Are we going to regenerate the 7.4.1 tar ball?

No. There is no difference other than some trailing spaces between
what Bruce committed and what I put in yesterday.

(It might be good if we had a more standardized way of generating
HISTORY though. I tried a couple different versions of lynx and
got a couple different outputs, none perfectly matching whatever
version Bruce is using ...)

regards, tom lane

On Mon, 22 Dec 2003, Tom Lane wrote:

> Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> > Are we going to regenerate the 7.4.1 tar ball?
>
> No. There is no difference other than some trailing spaces between
> what Bruce committed and what I put in yesterday.
>
> (It might be good if we had a more standardized way of generating
> HISTORY though. I tried a couple different versions of lynx and
> got a couple different outputs, none perfectly matching whatever
> version Bruce is using ...)

Is this something that could be added to the 'make dist' target, so that
it happens as part of the bundle build? or maybe a 'make release_prep'
target could be created, that would include stuff like this that gets done
just before release?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

"Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> On Mon, 22 Dec 2003, Tom Lane wrote:
>> (It might be good if we had a more standardized way of generating
>> HISTORY though. I tried a couple different versions of lynx and
>> got a couple different outputs, none perfectly matching whatever
>> version Bruce is using ...)

> Is this something that could be added to the 'make dist' target, so that
> it happens as part of the bundle build?

Not a bad idea. AFAICS we have the generation of HISTORY down to a
script now; there's no reason for it to be in CVS at all. It'd be nice
to do the same for INSTALL, but I'm not sure if that takes any manual
twiddling or not. (Peter?)

The version of lynx that's on cvs.postgresql.org seems to produce okay
output (it's what I ended up using yesterday), so standardizing on that
wouldn't be a problem.

regards, tom lane

Tom Lane wrote:
> Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> > Are we going to regenerate the 7.4.1 tar ball?
>
> No. There is no difference other than some trailing spaces between
> what Bruce committed and what I put in yesterday.
>
> (It might be good if we had a more standardized way of generating
> HISTORY though. I tried a couple different versions of lynx and
> got a couple different outputs, none perfectly matching whatever
> version Bruce is using ...)

Right. I regenerated because Peter had mentioned he was getting poor
output, so I figured I should make sure it was fresh, but the changes
were just trailing spaces.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Tom Lane wrote:
> "Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> > On Mon, 22 Dec 2003, Tom Lane wrote:
> >> (It might be good if we had a more standardized way of generating
> >> HISTORY though. I tried a couple different versions of lynx and
> >> got a couple different outputs, none perfectly matching whatever
> >> version Bruce is using ...)
>
> > Is this something that could be added to the 'make dist' target, so that
> > it happens as part of the bundle build?
>
> Not a bad idea. AFAICS we have the generation of HISTORY down to a
> script now; there's no reason for it to be in CVS at all. It'd be nice
> to do the same for INSTALL, but I'm not sure if that takes any manual
> twiddling or not. (Peter?)

INSTALL pulls the release number from configure.in, or configure.

> The version of lynx that's on cvs.postgresql.org seems to produce okay
> output (it's what I ended up using yesterday), so standardizing on that
> wouldn't be a problem.

I have:

Lynx Version 2.8.3rel.1 (23 Apr 2000)
Built on bsdi4.3 Jun 5 2001 12:07:55

and I see postgresql.org has:

Lynx Version 2.8.5dev.16 (01 Jun 2003)
libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 0.9.7b
Built on freebsd4.8 Sep 1 2003 04:28:28

The only problem with removing HISTORY from CVS is that we will not have
an easily reable list of release changes _until_ we package the release.
Perhaps we should keep HISTORY in CVS, but regenerate it on tarball
packaging, and INSTALL too.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Mon, 22 Dec 2003, Bruce Momjian wrote:

> The only problem with removing HISTORY from CVS is that we will not have
> an easily reable list of release changes _until_ we package the release.
> Perhaps we should keep HISTORY in CVS, but regenerate it on tarball
> packaging, and INSTALL too.

Confused here, but how "up to date" is HISTORY in CVS to start with? I
don't go out of my way to watch for them, but commits to HISTORY don't
seem to be all that often to start with ... and how many ppl actually look
at the HISTORY file *except* at release time?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On Mon, Dec 22, 2003 at 12:17:32PM -0500, Bruce Momjian wrote:

> The only problem with removing HISTORY from CVS is that we will not have
> an easily reable list of release changes _until_ we package the release.
> Perhaps we should keep HISTORY in CVS, but regenerate it on tarball
> packaging, and INSTALL too.

What about having them generated from some Make target, so the curious
user could generate it on his own, and is also built by Marc's
ficticious package-prep target?

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"El sabio habla porque tiene algo que decir;
el tonto, porque tiene que decir algo" (Platon).

Marc G. Fournier wrote:
> On Mon, 22 Dec 2003, Bruce Momjian wrote:
>
> > The only problem with removing HISTORY from CVS is that we will not have
> > an easily reable list of release changes _until_ we package the release.
> > Perhaps we should keep HISTORY in CVS, but regenerate it on tarball
> > packaging, and INSTALL too.
>
> Confused here, but how "up to date" is HISTORY in CVS to start with? I
> don't go out of my way to watch for them, but commits to HISTORY don't
> seem to be all that often to start with ... and how many ppl actually look
> at the HISTORY file *except* at release time?

Usually I modify HISTORY during beta, then move it to release.sgml, but
I could reverse that and do edits in release.sgml then regenerate and
copy HISTORY. It is mostly during beta. We could throw a URL into the
HISTORY file telling people where to look for the generated release
notes.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Alvaro Herrera wrote:
> On Mon, Dec 22, 2003 at 12:17:32PM -0500, Bruce Momjian wrote:
>
> > The only problem with removing HISTORY from CVS is that we will not have
> > an easily reable list of release changes _until_ we package the release.
> > Perhaps we should keep HISTORY in CVS, but regenerate it on tarball
> > packaging, and INSTALL too.
>
> What about having them generated from some Make target, so the curious
> user could generate it on his own, and is also built by Marc's
> ficticious package-prep target?

He would have to have the SGML tools installed, and that isn't
trivial/likely.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Mon, 22 Dec 2003, Bruce Momjian wrote:

> Marc G. Fournier wrote:
> > On Mon, 22 Dec 2003, Bruce Momjian wrote:
> >
> > > The only problem with removing HISTORY from CVS is that we will not have
> > > an easily reable list of release changes _until_ we package the release.
> > > Perhaps we should keep HISTORY in CVS, but regenerate it on tarball
> > > packaging, and INSTALL too.
> >
> > Confused here, but how "up to date" is HISTORY in CVS to start with? I
> > don't go out of my way to watch for them, but commits to HISTORY don't
> > seem to be all that often to start with ... and how many ppl actually look
> > at the HISTORY file *except* at release time?
>
> Usually I modify HISTORY during beta, then move it to release.sgml, but
> I could reverse that and do edits in release.sgml then regenerate and
> copy HISTORY. It is mostly during beta. We could throw a URL into the
> HISTORY file telling people where to look for the generated release
> notes.

I'm neither here nor there on it ... it just seems weird to include
'derived files' in CVS that really aren't required (ie. bison stuff is
required) ... IMHO, it would be like re-generating the whole docs and
checking it into CVS ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On Mon, 22 Dec 2003, Bruce Momjian wrote:

> Alvaro Herrera wrote:
> > On Mon, Dec 22, 2003 at 12:17:32PM -0500, Bruce Momjian wrote:
> >
> > > The only problem with removing HISTORY from CVS is that we will not have
> > > an easily reable list of release changes _until_ we package the release.
> > > Perhaps we should keep HISTORY in CVS, but regenerate it on tarball
> > > packaging, and INSTALL too.
> >
> > What about having them generated from some Make target, so the curious
> > user could generate it on his own, and is also built by Marc's
> > ficticious package-prep target?
>
> He would have to have the SGML tools installed, and that isn't
> trivial/likely.

True, but Peter could very easily have HISTORY generated and on the web
page as part of his docs build process ... then 'HISTORY' in CVS would
just be a URL to that online version, while 'HISTORY' in a release would
be the full HISTORY file ... ?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:
> On Mon, 22 Dec 2003, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> > > On Mon, 22 Dec 2003, Bruce Momjian wrote:
> > >
> > > > The only problem with removing HISTORY from CVS is that we will not have
> > > > an easily reable list of release changes _until_ we package the release.
> > > > Perhaps we should keep HISTORY in CVS, but regenerate it on tarball
> > > > packaging, and INSTALL too.
> > >
> > > Confused here, but how "up to date" is HISTORY in CVS to start with? I
> > > don't go out of my way to watch for them, but commits to HISTORY don't
> > > seem to be all that often to start with ... and how many ppl actually look
> > > at the HISTORY file *except* at release time?
> >
> > Usually I modify HISTORY during beta, then move it to release.sgml, but
> > I could reverse that and do edits in release.sgml then regenerate and
> > copy HISTORY. It is mostly during beta. We could throw a URL into the
> > HISTORY file telling people where to look for the generated release
> > notes.
>
> I'm neither here nor there on it ... it just seems weird to include
> 'derived files' in CVS that really aren't required (ie. bison stuff is
> required) ... IMHO, it would be like re-generating the whole docs and
> checking it into CVS ...

Agreed, it is weird. One idea would be to check a HISTORY file into CVS
that contains only a link to the developer HTML docs, then overwrite it
with the proper contents on tar build.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Marc G. Fournier wrote:
> On Mon, 22 Dec 2003, Bruce Momjian wrote:
>
> > Alvaro Herrera wrote:
> > > On Mon, Dec 22, 2003 at 12:17:32PM -0500, Bruce Momjian wrote:
> > >
> > > > The only problem with removing HISTORY from CVS is that we will not have
> > > > an easily reable list of release changes _until_ we package the release.
> > > > Perhaps we should keep HISTORY in CVS, but regenerate it on tarball
> > > > packaging, and INSTALL too.
> > >
> > > What about having them generated from some Make target, so the curious
> > > user could generate it on his own, and is also built by Marc's
> > > ficticious package-prep target?
> >
> > He would have to have the SGML tools installed, and that isn't
> > trivial/likely.
>
> True, but Peter could very easily have HISTORY generated and on the web
> page as part of his docs build process ... then 'HISTORY' in CVS would
> just be a URL to that online version, while 'HISTORY' in a release would
> be the full HISTORY file ... ?

Yep, I just came to the same conclusion.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

> On Mon, 22 Dec 2003, Bruce Momjian wrote:
>> The only problem with removing HISTORY from CVS is that we will not have
>> an easily reable list of release changes _until_ we package the release.

Nonsense. Point 'em to
http://developer.postgresql.org/docs/postgres/release.html

>> Perhaps we should keep HISTORY in CVS, but regenerate it on tarball
>> packaging, and INSTALL too.

It's really bogus to have two versions of the same information in CVS.
If we simply agreed that the SGML versions are the masters, we could
keep those up-to-date, and generate the plain-text versions whenever a
tarball is rolled.

"Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> Confused here, but how "up to date" is HISTORY in CVS to start with?

One reason it's not is the confusion over which version is the master.
Last cycle, Peter encouraged people to add quick-and-dirty release notes
into release.sgml when important changes are made, and I thought that
worked pretty well.

regards, tom lane

Tom Lane wrote:
> "Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> > Confused here, but how "up to date" is HISTORY in CVS to start with?
>
> One reason it's not is the confusion over which version is the master.
> Last cycle, Peter encouraged people to add quick-and-dirty release notes
> into release.sgml when important changes are made, and I thought that
> worked pretty well.

Would you be more specific? How did it work well?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> Last cycle, Peter encouraged people to add quick-and-dirty release notes
>> into release.sgml when important changes are made, and I thought that
>> worked pretty well.

> Would you be more specific? How did it work well?

There was a place for people to look to see what interesting stuff was
in CVS tip. We had about thirty entries at the end of the 7.4 devel
cycle:
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/doc/src/sgml/release.sgml?rev=1.208&content-type=text/x-cvsweb-markup

Now, I dunno how many people actually made use of it, but if it were
publicized and maintained more faithfully, I think people would use it.

regards, tom lane

Tom Lane wrote:
> (It might be good if we had a more standardized way of generating
> HISTORY though. I tried a couple different versions of lynx and
> got a couple different outputs, none perfectly matching whatever
> version Bruce is using ...)

There lies the problem. Making these text files is still guesswork
and/or manual polishing, because the tools always change and no one
tool works well on at least HISTORY and INSTALL at the same time. The
HISTORY generatation has a makefile rule that appears to work well for
Bruce, but I actually wrote it to work on my machine, but now I get the
same problem that you state. For INSTALL, lynx gives terrible results,
and for the past few releases I've been using a tool named html2txt,
but that still requires manual cleanup. In short, automatic generation
of text files that works every time is still an open problem.