Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE r ...
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. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE r ...
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: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (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 [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE r ...
Tatsuo Ishii [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
On Mon, 22 Dec 2003, Tom Lane wrote: Tatsuo Ishii [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE r ...
Marc G. Fournier [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
Tom Lane wrote: Tatsuo Ishii [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (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 [EMAIL PROTECTED])
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
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). ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
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 [EMAIL PROTECTED] | (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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
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 [EMAIL PROTECTED] | (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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
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 [EMAIL PROTECTED] | (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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
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 [EMAIL PROTECTED] | (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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE r ...
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 [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE r ...
Bruce Momjian [EMAIL PROTECTED] 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.208content-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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
