pgsql-server/doc/src/sgml Tag: REL7_4_STABLE r ...
CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: petere@svr1.postgresql.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@svr1.postgresql.org 03/12/21 17:36:34Modified files:
doc/src/sgml : Tag: REL7_4_STABLE release.sgmlLog 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@candle.pha.pa.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
Show quoted text
Peter Eisentraut - PostgreSQL wrote:
CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: petere@svr1.postgresql.org 03/12/21 17:36:34Modified files:
doc/src/sgml : Tag: REL7_4_STABLE release.sgmlLog 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@candle.pha.pa.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@postgresql.org)
Tatsuo Ishii <t-ishii@sra.co.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@sra.co.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@hub.org Yahoo!: yscrappy ICQ: 7615664
"Marc G. Fournier" <scrappy@postgresql.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@sra.co.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@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Tom Lane wrote:
"Marc G. Fournier" <scrappy@postgresql.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@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073On 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@hub.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@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Alvaro 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@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073On 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@hub.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@hub.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@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Marc 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@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073On 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@postgresql.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@postgresql.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@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian <pgman@candle.pha.pa.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.