Обсуждение: Request temporary freeze of libpgtcl chapter in manual
I have a new project to extend and finish up pgtcl, the Tcl interface to PostgreSQL. This continues the effort to unbundle interfaces from the PostgreSQL core. Along with the software, I will be releasing a stand-alone reference manual, which started life as libpgtcl.sgml from the PostgreSQL core reference manual, but has been expanded, and portions were rewritten. I would like to request that no changes be made to the libpgtcl chapter in the PostgreSQL reference manual, at least for the near term, beyond file revision 1.40 in CVS. Otherwise, I can't promise any changes you make will end up in my version of the manual, in the event that the unbundling effort is successful. Is this OK?
At 1:01 AM +0000 2/20/04, ljb wrote: >I would like to request that no changes be made to the libpgtcl >chapter in the PostgreSQL reference manual, at least for the near term, >beyond file revision 1.40 in CVS. Otherwise, I can't promise any changes >you make will end up in my version of the manual, in the event that the >unbundling effort is successful. Is this OK? I'm not contributing, so it's not an issue for me. However isn't the whole point of CVS to make re-merging changes like this easy? -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
Henry B. Hotz wrote: > > At 1:01 AM +0000 2/20/04, ljb wrote: > >I would like to request that no changes be made to the libpgtcl > >chapter in the PostgreSQL reference manual, at least for the near term, > >beyond file revision 1.40 in CVS. Otherwise, I can't promise any changes > >you make will end up in my version of the manual, in the event that the > >unbundling effort is successful. Is this OK? > > I'm not contributing, so it's not an issue for me. > > However isn't the whole point of CVS to make re-merging changes like this easy? Yes, in normal cases CVS would handle this, but the goal is to unbundle the Pgtcl interface and its manual from the core PostgreSQL product. This means there will be no more Pgtcl chapter in the PostgreSQL manual - just like there is no longer a chapter on the Perl interface. I've made so many changes to my version of this material that it is unlikely either could be merged into the other. My new Pgtcl version and its manual have now been released at: http://gborg.postgresql.org/project/pgtclng/ There is an unpacked version of the manual for viewing on my own site: http://lbayuk.home.mindspring.com/pgtcldocs/ but this is temporary, and I would like to find a more permanent place for it. There doesn't seem to be a way to put a docbook-generated manual on gborg.postgresql.org. I wonder if they would allow it on techdocs.postgresql.org.
On Wednesday 03 March 2004 21:30, L J Bayuk wrote: > Henry B. Hotz wrote: > > At 1:01 AM +0000 2/20/04, ljb wrote: > > >I would like to request that no changes be made to the libpgtcl > > >chapter in the PostgreSQL reference manual, at least for the near term, > > >beyond file revision 1.40 in CVS. Otherwise, I can't promise any > > > changes you make will end up in my version of the manual, in the event > > > that the unbundling effort is successful. Is this OK? > > > > I'm not contributing, so it's not an issue for me. > > > > However isn't the whole point of CVS to make re-merging changes like this > > easy? > > Yes, in normal cases CVS would handle this, but the goal is to unbundle > the Pgtcl interface and its manual from the core PostgreSQL product. This > means there will be no more Pgtcl chapter in the PostgreSQL manual - just > like there is no longer a chapter on the Perl interface. I've made so many > changes to my version of this material that it is unlikely either could > be merged into the other. > > My new Pgtcl version and its manual have now been released at: > http://gborg.postgresql.org/project/pgtclng/ > There is an unpacked version of the manual for viewing on my own site: > http://lbayuk.home.mindspring.com/pgtcldocs/ > but this is temporary, and I would like to find a more permanent place > for it. There doesn't seem to be a way to put a docbook-generated > manual on gborg.postgresql.org. I wonder if they would allow it on > techdocs.postgresql.org. I'd prefer to have the documentation live closer to the project than to have it up on techdocs, though techdocs is probably better than someone personal home page. Chris, is there some way to accomplish this with gborg? Josh, is this something that Gforge would give us? Anyone know what the guys working on the perl interface have done? Robert Treat -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
xzilla@users.sourceforge.net wrote: >... > > I'd prefer to have the documentation live closer to the project than to have > it up on techdocs, though techdocs is probably better than someone personal > home page. > > Chris, is there some way to accomplish this with gborg? > > Josh, is this something that Gforge would give us? > > Anyone know what the guys working on the perl interface have done? My mistake. I see that the Perl interface documentation was never part of the PostgreSQL Programmer's Manual. The Perl interface documentation lives inside the Pg.pm file and ends up installed and readable with perldoc. Bad example. I think there was a request on Gborg about project documentation, and the answer was to use the "genpage" feature. That's OK for a few pages with little cross-referencing, but I don't think it is practical for DocBook-generated manuals. Perhaps it isn't that important to have an unpacked version of the manual readable on the web. But for this first release, I just wanted to make it easier for people to look at, especially those who might be asking: are we unbundled yet?