You can subscribe to this list here.
2001 |
Jan
|
Feb
(1) |
Mar
|
Apr
(36) |
May
(56) |
Jun
(1) |
Jul
(5) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
|
Mar
(15) |
Apr
(5) |
May
(7) |
Jun
(5) |
Jul
(3) |
Aug
(6) |
Sep
(3) |
Oct
(8) |
Nov
(23) |
Dec
(21) |
2003 |
Jan
(25) |
Feb
(37) |
Mar
(59) |
Apr
(11) |
May
(8) |
Jun
(24) |
Jul
(18) |
Aug
(29) |
Sep
(30) |
Oct
(11) |
Nov
(20) |
Dec
(5) |
2004 |
Jan
(43) |
Feb
(24) |
Mar
(61) |
Apr
(14) |
May
(23) |
Jun
(50) |
Jul
(13) |
Aug
(56) |
Sep
(55) |
Oct
(64) |
Nov
(94) |
Dec
(27) |
2005 |
Jan
(40) |
Feb
(10) |
Mar
(55) |
Apr
(20) |
May
(16) |
Jun
(6) |
Jul
(58) |
Aug
(38) |
Sep
(5) |
Oct
(6) |
Nov
(71) |
Dec
(99) |
2006 |
Jan
(6) |
Feb
(15) |
Mar
(22) |
Apr
(9) |
May
(31) |
Jun
(35) |
Jul
(47) |
Aug
(18) |
Sep
(21) |
Oct
(24) |
Nov
(63) |
Dec
(79) |
2007 |
Jan
(22) |
Feb
(40) |
Mar
(47) |
Apr
(69) |
May
(22) |
Jun
(20) |
Jul
(25) |
Aug
(13) |
Sep
(7) |
Oct
(44) |
Nov
(76) |
Dec
(1) |
2008 |
Jan
(26) |
Feb
(30) |
Mar
(120) |
Apr
(14) |
May
(22) |
Jun
(40) |
Jul
(48) |
Aug
(7) |
Sep
(34) |
Oct
(31) |
Nov
|
Dec
(30) |
2009 |
Jan
(9) |
Feb
(6) |
Mar
(9) |
Apr
(2) |
May
(9) |
Jun
|
Jul
(31) |
Aug
(32) |
Sep
(15) |
Oct
(23) |
Nov
|
Dec
(9) |
2010 |
Jan
(19) |
Feb
(9) |
Mar
|
Apr
|
May
(9) |
Jun
(6) |
Jul
(8) |
Aug
(21) |
Sep
(10) |
Oct
(1) |
Nov
(3) |
Dec
(33) |
2011 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
(10) |
May
|
Jun
(9) |
Jul
(23) |
Aug
(2) |
Sep
(35) |
Oct
(36) |
Nov
|
Dec
(4) |
2012 |
Jan
(3) |
Feb
(8) |
Mar
(3) |
Apr
|
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
(12) |
Nov
(12) |
Dec
|
2013 |
Jan
(18) |
Feb
(5) |
Mar
(1) |
Apr
|
May
|
Jun
(5) |
Jul
|
Aug
(21) |
Sep
|
Oct
(5) |
Nov
(1) |
Dec
(11) |
2014 |
Jan
|
Feb
|
Mar
(4) |
Apr
(2) |
May
|
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
(29) |
Dec
|
2015 |
Jan
|
Feb
|
Mar
(14) |
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(7) |
Sep
(5) |
Oct
|
Nov
(6) |
Dec
(3) |
2016 |
Jan
(14) |
Feb
(9) |
Mar
(33) |
Apr
(12) |
May
(18) |
Jun
(3) |
Jul
|
Aug
(15) |
Sep
|
Oct
|
Nov
|
Dec
(22) |
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(10) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(44) |
Nov
(32) |
Dec
(8) |
2018 |
Jan
(2) |
Feb
(25) |
Mar
(16) |
Apr
(11) |
May
(1) |
Jun
(19) |
Jul
(3) |
Aug
|
Sep
|
Oct
(25) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(3) |
2020 |
Jan
(29) |
Feb
(28) |
Mar
(13) |
Apr
(13) |
May
(107) |
Jun
(75) |
Jul
(57) |
Aug
(36) |
Sep
(3) |
Oct
(4) |
Nov
(4) |
Dec
(1) |
2021 |
Jan
(2) |
Feb
(13) |
Mar
(5) |
Apr
(6) |
May
(44) |
Jun
(9) |
Jul
(9) |
Aug
(3) |
Sep
(11) |
Oct
(5) |
Nov
(14) |
Dec
(19) |
2022 |
Jan
(1) |
Feb
|
Mar
|
Apr
(4) |
May
(1) |
Jun
(1) |
Jul
(13) |
Aug
(6) |
Sep
(2) |
Oct
(7) |
Nov
(2) |
Dec
|
2023 |
Jan
(2) |
Feb
|
Mar
(13) |
Apr
(2) |
May
(31) |
Jun
(12) |
Jul
(5) |
Aug
(5) |
Sep
(27) |
Oct
(7) |
Nov
(25) |
Dec
(7) |
2024 |
Jan
(11) |
Feb
(27) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Tilo M. <tm...@al...> - 2003-09-18 22:08:58
|
Hi, "Paul Vinkenoog" <pa...@vi...> schrieb im Newsbeitrag news:Pin...@so...... > Hi Tilo, > > >> Can you please ask them not to remove docbook and docbookx? Because > >> they are now (since I unzipped the archives) full of stuff we need, > >> and I've removed the zipfiles. (...) > > > > I don't think the admins have yet opened a SF support for this, so > > no need to get active here. > > The danger may be in the "yet". What if an admin finally gets round to > read your mail and asks SF to purge all that stuff? Or do you think > they'll contact you anyway before they do that? (I don't know how this > usually works.) OK I have sent a message to firebird-admin. > Greetings, > Paul Vinkenoog -- Regards, Tilo Muetze -- Marathon - The SQL Tool for Firebird & InterBase http://gmarathon.sourceforge.net |
From: Tilo M. <tm...@al...> - 2003-09-18 22:01:04
|
Hi Paul, "Paul Vinkenoog" <pa...@vi...> schrieb im Newsbeitrag news:Pin...@s4...... > Hi Tilo, > > > [ about the empty folder src\docs\firebirddocs\images: ] > > > Let's comment it out then, and uncomment it as soon as something is > > placed in that folder. And when it is no longer empty, it will also > > no longer be pruned by "update -P", so that part of the problem will > > solve itself. > > Meanwhile I've thought of something that may be better: > > - create a file Readme.txt in the images dir; > - change the lines in the *html targets in build.xml that now read: > <fileset dir="${src.dir}/docs/firebirddocs/images"/> > to: > <fileset dir="${src.dir}/docs/firebirddocs/images" > excludes="Readme.txt"/> > > The first step will prevent the local dir to be deleted by update -P. > The second step will prevent Readme.txt to be copied to the dist tree. > > The advantage is that we won't have to change build.xml back and > forth; this solution will work whether image is "empty" (but for > Readme.txt) or not. > > Readme.txt must contain a few lines to explain why it is there and > why it shouldn't be deleted. I call it Readme.txt instead of e.g. > Dummy.txt because this makes it more likely that someone will read > the contents before he decides to delete it. > > What do you think? Go for that workaround, later when the first image is used in the docs we can rollback that change. > Greetings, > Paul Vinkenoog -- Regards, Tilo Muetze -- Marathon - The SQL Tool for Firebird & InterBase http://gmarathon.sourceforge.net |
From: Paul V. <pa...@vi...> - 2003-09-14 12:11:42
|
Hi Tilo, > [ about the empty folder src\docs\firebirddocs\images: ] > Let's comment it out then, and uncomment it as soon as something is > placed in that folder. And when it is no longer empty, it will also > no longer be pruned by "update -P", so that part of the problem will > solve itself. Meanwhile I've thought of something that may be better: - create a file Readme.txt in the images dir; - change the lines in the *html targets in build.xml that now read: <fileset dir="${src.dir}/docs/firebirddocs/images"/> to: <fileset dir="${src.dir}/docs/firebirddocs/images" excludes="Readme.txt"/> The first step will prevent the local dir to be deleted by update -P. The second step will prevent Readme.txt to be copied to the dist tree. The advantage is that we won't have to change build.xml back and forth; this solution will work whether image is "empty" (but for Readme.txt) or not. Readme.txt must contain a few lines to explain why it is there and why it shouldn't be deleted. I call it Readme.txt instead of e.g. Dummy.txt because this makes it more likely that someone will read the contents before he decides to delete it. What do you think? Greetings, Paul Vinkenoog |
From: Paul V. <pa...@vi...> - 2003-09-13 23:26:14
|
Hi Tilo (last one for today), >> 1. A how-to on getting the manual module to work, with: >> - getting and installing Java 2 > > Here I suggest a simple link to the SUN download page. Yes, that's what I had in mind: no lengthy explanations, just tell them what they need (at least JRE; JDK if they want to) and where to get it. >> - getting and installing CVS > > Why not use this description? > http://sourceforge.net/docman/display_doc.php?docid=766&group_id=1 It's very lengthy, and specific to WinCVS. I'd prefer to give pointers to command line CVS, WinCVS and TortoiseCVS. WinCVS is fine, but TortoiseCVS is so easy and intuitive that it's almost a laugh! It also has SSH built in, unlike WinCVS. After that, a short explanation of how to ckeckout the manual module, with examples for all three programs. Same for update -dP. With read-only access, that's all they'll ever need. > I think our goal should be a nightly build of the html docs which > then can be made available online. That would be nice. But is this automatable on SF? Greetings, Paul Vinkenoog |
From: Paul V. <pa...@vi...> - 2003-09-13 23:00:06
|
Hi Tilo, >> Can you please ask them not to remove docbook and docbookx? Because >> they are now (since I unzipped the archives) full of stuff we need, >> and I've removed the zipfiles. (...) > > I don't think the admins have yet opened a SF support for this, so > no need to get active here. The danger may be in the "yet". What if an admin finally gets round to read your mail and asks SF to purge all that stuff? Or do you think they'll contact you anyway before they do that? (I don't know how this usually works.) Greetings, Paul Vinkenoog |
From: Paul V. <pa...@vi...> - 2003-09-13 22:53:57
|
Hi Tilo, [ about the empty folder src\docs\firebirddocs\images: ] > Yes if you wish we can comment out this dir for the moment, but > images which are used in the actual documentation should go in here. > >> The images to be used for the HTML targets now live in >> src\docs\images > > No, this dir is intended for image files which are used for the > structure of the manual. OK, that makes sense. Let's comment it out then, and uncomment it as soon as something is placed in that folder. And when it is no longer empty, it will also no longer be pruned by "update -P", so that part of the problem will solve itself. Greetings, Paul Vinkenoog |
From: Paul V. <pa...@vi...> - 2003-09-13 22:46:04
|
Hi all, > BTW: A build under Linux failed because bash choked on the newline > escapes followed by comment lines. Evidently it escaped the #'s too > and saw the subsequent '-----' as commands! When I removed the > in-between comment lines from my local copy, everything worked. Well, it turns out to be a documented bash thing: if a # is glued to the previous word, it is not considered to be a comment character, so e.g. echo hihihi # hahaha echoes "hihihi", but echo hihihi# hahaha echoes "hihihi# hahaha" The same principle is at work in build.sh. It can be fixed in several ways, but my proposition is to do it like this, because this makes build.sh and build.bat look more alike, and therefore more easily maintainable as a pair (I think): --- BEGIN build.sh --- #! /bin/sh if [ "$JAVA_HOME" == "" ] ; then echo " Error: The JAVA_HOME environment variable is not set." echo " You must set it to point at your JDK or JRE distribution," echo " e.g. JAVA_HOME=/usr/java/j2sdk" exit 1 fi # set up the classpath _CP_ : # ----- ant libraries: ------ _CP_=../../lib/ant.jar _CP_=$_CP_:../../lib/optional.jar # ----- saxon libraries: ------ _CP_=$_CP_:../../lib/saxon.jar # ----- FOP libraries: ------ _CP_=$_CP_:../../lib/fop.jar _CP_=$_CP_:../../lib/batik.jar _CP_=$_CP_:../../lib/avalon-framework-cvs-20020315.jar _CP_=$_CP_:../../lib _CP_=$_CP_:$JAVA_HOME/lib/tools.jar java -Xmx100000000 -showversion -classpath $_CP_ org.apache.tools.ant.Main $* --- END build.sh I have this in a working copy of my working copy now, and it does the job (also tested with JAVA_HOME empty of course). Greetings, Paul Vinkenoog |
From: Tilo M. <tm...@al...> - 2003-09-13 16:16:52
|
Hi Paul, "Paul Vinkenoog" <pa...@vi...> schrieb im Newsbeitrag news:Pin...@so...... > 1. A how-to on getting the manual module to work, with: > - getting and installing Java 2 Here I suggest a simple link to the SUN download page. Additionally we can add the stuff which is really needed to get our manual module compiled (CLASSPATH,...). > - getting and installing CVS Why not use this description? http://sourceforge.net/docman/display_doc.php?docid=766&group_id=1 > - checking out the Firebird manual module > - building the docs that are already there > - what to do if things don't work Agreed. > This would be for people who are at least considering to write > docs. If we make such a how-to and we think it's good, we should > have it placed in the Files section at SourceFource, and ask > IBPhoenix to place a link (or even place the entire how-to as a > webpage). Otherwise, you would first have to install Java 2 and > CVS, check out the manual module and build the docs in order to > read how to accomplish the things you have just done :-) I think our goal should be a nightly build of the html docs which then can be made available online. > 2. A how-to for those who really _are_ going to write docs, with: > - how to pick a subject and where to discuss/announce it > - why we really want you to write DocBook XML > - general as well as fbdocs-specific DocBook instructions + tips > - how to structure your document > - style guidelines/tips > - how and where to ask for commit rights > - dos and don'ts if you have received commit rights Sounds good. We can use preface.xml where most of the required topics is already available. > Looking forward to your comments, > Paul Vinkenoog -- Regards, Tilo Muetze -- Marathon - The SQL Tool for Firebird & InterBase http://gmarathon.sourceforge.net |
From: Tilo M. <tm...@al...> - 2003-09-13 15:39:56
|
Hi Paul, "Paul Vinkenoog" <pa...@vi...> schrieb im Newsbeitrag news:Pin...@so...... > Can you please ask them not to remove docbook and docbookx? Because > they are now (since I unzipped the archives) full of stuff we need, > and I've removed the zipfiles. Or maybe even ask them to ignore the > entire request. In callouts there are only 10 files or so, we can do > that ourselves easily. Only the directory can't be removed by us, like > you pointed out earlier. I don't think the admins have yet opened a SF support for this, so no need to get active here. -- Regards, Tilo Muetze -- Marathon - The SQL Tool for Firebird & InterBase http://gmarathon.sourceforge.net |
From: Tilo M. <tm...@al...> - 2003-09-13 15:37:35
|
Hi Paul, "Paul Vinkenoog" <pa...@vi...> schrieb im Newsbeitrag news:Pin...@s4...... > Hello all, > > The CVS directory src\docs\firebirddocs\images is empty, but it is > referenced twice in build.xml as a source to copy files from. > > As such, this is no problem, as long as the directory is there in the > working copy. But if you checkout or update with the -P flag (as some > frontends do by default), the empty directory won't be there and you > get a build error later for the targets defaulthtml and printablehtml. > > If we think this dir will remain empty for awhile - or forever - it > might be better to comment out those lines in build.xml, or even > remove them. Yes if you wish we can comment out this dir for the moment, but images which are used in the actual documentation should go in here. > The images to be used for the HTML targets now live in src\docs\images No, this dir is intended for image files which are used for the structure of the manual. -- Regards, Tilo Muetze -- Marathon - The SQL Tool for Firebird & InterBase http://gmarathon.sourceforge.net |
From: Paul V. <pa...@vi...> - 2003-09-13 15:31:18
|
Hi Tilo, [ docs/images/callouts ] > Yes this is one of the dirs where I was too lazy to do it manually, > therefore I've sent this mail to the admins. But if you wish I can > do it in mid Oct myself. > <<< > I have updated the 'manual' module so that it is now compatible with > the latest Java versions. Some files have become obsolete during > this process, so can someone of the admins please open a SF request > so that they remove the following files and dirs. Or should I do it > manually? > manual/src/docs/docbook - everything except docbook-xsl-1.60.1.zip > manual/src/docs/docbookx - everything except docbkx412.zip > manual/src/docs/images/callouts - remove completely > >>> Can you please ask them not to remove docbook and docbookx? Because they are now (since I unzipped the archives) full of stuff we need, and I've removed the zipfiles. Or maybe even ask them to ignore the entire request. In callouts there are only 10 files or so, we can do that ourselves easily. Only the directory can't be removed by us, like you pointed out earlier. Greetings, Paul Vinkenoog |
From: Paul V. <pa...@vi...> - 2003-09-13 15:12:52
|
Hi Tilo, > Sorry if this message appears twice, but seems my first one didn't > make it to the newsgroup... I received it via the mailing list yesterday. The newsgroup has a long delay sometimes, and it also seems to happen that messages don't make it there at all. I do use it, because it's great to browse with Agent, but I only post through the mailing list, to make sure my messages arrive - and arrive reasonably quickly. > I still would go with 2., but you can decide because I don't have > time before mid Oct.. In the meantime I went for 1 and unzipped both archives to the right folders, adapted the ReadMe and comitted the changes. Provided Java and JAVA_HOME are set up, everything works out of the box now after a checkout or update. At least for project members. An anonymous connection still gives you the old tree; same with ViewCVS at SF. I committed yesterday late afternoon but it seems the delay can be several days for anon access :-( BTW: A build under Linux failed because bash choked on the newline escapes followed by comment lines. Evidently it escaped the #'s too and saw the subsequent '-----' as commands! When I removed the in-between comment lines from my local copy, everything worked. Maybe it's just my system (SuSE 7.1, more than 2 yrs old by now - I still have the receipt, shall I go complain at Karstadt Trier? ;-)) Anyway I'll try it on another Linux too. If this happens on more systems we'll have to change build.sh (but it's an easy one, almost as easy as writing docs :-)) I've also applied Olivier's fix. Greetings, Paul Vinkenoog |
From: Paul V. <pa...@vi...> - 2003-09-13 14:36:55
|
Hello, > This message is intended for everybody who is planning or > considering to help with the Firebird docs. > > As said earlier, practically everything will have to be written from > scratch. Helen Borrie, who has lots of experience with doc writing, > advised us to develop a how-to on writing Firebird docs. I've received some reactions off-list, and they made clear that there really are people who want to write docs, and that a how-to and/or guidelines would be greatly appreciated. So... let's make a how-to. What should go in it? My first, rough idea looks something like this: 1. A how-to on getting the manual module to work, with: - getting and installing Java 2 - getting and installing CVS - checking out the Firebird manual module - building the docs that are already there - what to do if things don't work This would be for people who are at least considering to write docs. If we make such a how-to and we think it's good, we should have it placed in the Files section at SourceFource, and ask IBPhoenix to place a link (or even place the entire how-to as a webpage). Otherwise, you would first have to install Java 2 and CVS, check out the manual module and build the docs in order to read how to accomplish the things you have just done :-) A lot of the above information is already out there somewhere - I can't find it on www.ibphoenix.com right now but maybe I didn't look in the right place - but it's scattered and outdated here and there. David Jencks wrote quite a bit of useful stuff; it's in the manual module. 2. A how-to for those who really _are_ going to write docs, with: - how to pick a subject and where to discuss/announce it - why we really want you to write DocBook XML - general as well as fbdocs-specific DocBook instructions + tips - how to structure your document - style guidelines/tips - how and where to ask for commit rights - dos and don'ts if you have received commit rights Of course the two documents should refer to each other. If they turn out really small, they might even be combined into one. Again, these are just rough outlines as they come up in my head right now, I'm not at all saying that it must be like this! Looking forward to your comments, Paul Vinkenoog |
From: Tilo M. <tm...@al...> - 2003-09-13 14:16:57
|
Sorry if this message appears twice, but seems my first one didn't make it to the newsgroup... Hi, "Paul Vinkenoog" <pa...@vi...> schrieb im Newsbeitrag news:Pin...@so...... > Hello all - but especially Tilo this time, > > We still have those two zips in the CVS tree, and lots of obsolete > files and subdirs that should be replaced by the zip contents. One of > the zips also unpacks awkwardly, creating a subdir that shouldn't be > there at all. We can fix this in two ways: > > 1. Unpack both zips, moving the contents to the right place where > necessary, and commit to CVS. Obsolete files not overwritten by > content from the zips can be sent to the attic; obsolete subdirs > can either stay in place empty or we must have an admin ask SF to > remove them. > > 2. Repack the troublemaking archive in such a way that it unzips into > the right subdir, and leave the two zips in CVS. Move obsolete > stuff to attic and/or... same as above. 1. costs more time for us but it's easier for writers. Anyway I'm still not convinced that unzipping make things that much complicated. > Personally I have a strong preference for solution 1, because a) CVS > is a "text thing", and b) unzipping into CVS minimizes the extra steps > a body has to take after checking out the manual module. An additional > benefit is that if we upgrade the DocBook archives and we have things > unzipped in CVS, we can easily use cvs diff if problems arise, to see > what has changed, and how, and where. We can't do that with binaries. The most problems that arise while using a new Docbook and Java releases are related to the libraries (.jar). > However, I can live with solution 2 as well. But the present situation > makes things unnecessarily complicated. Agreed, at least the zip paths should be correct. > Tilo, what do you think is best? Whichever solution we choose, I > volunteer to do the work (or part of it); in fact it'll be a good > opportunity to see if my setup works, including committing. I still would go with 2., but you can decide because I don't have time before mid Oct.. > Another, smaller thing: Olivier Mascia's path fix should be applied, > for those who have Java in a path containing whitespace. I can do that > too if you like. Yes feel free to commit it. > After that, all we have to do is write those docs and we're done! :-) Easy one ;) > Greetings, > Paul Vinkenoog -- Regards, Tilo Muetze -- Marathon - The SQL Tool for Firebird & InterBase http://gmarathon.sourceforge.net |
From: Tilo M. <tm...@al...> - 2003-09-13 13:46:34
|
Hi, > I found this note from you in the Changelog (20.02.2003): > > docs/images/callouts - directory removed, the callout images from > DocBook XSL Stylsheet (docbook dir) are used > > But the dir and its contents are still there. Can they be removed, or > are they in use again? (Doesn't look like it.) Yes this is one of the dirs where I was too lazy to do it manually, therefore I've sent this mail to the admins. But if you wish I can do it in mid Oct myself. <<< I have updated the 'manual' module so that it is now compatible with the latest Java versions. Some files have become obsolete during this process, so can someone of the admins please open a SF request so that they remove the following files and dirs. Or should I do it manually? manual/src/docs/docbook - everything except docbook-xsl-1.60.1.zip manual/src/docs/docbookx - everything except docbkx412.zip manual/src/docs/images/callouts - remove completely >>> -- Regards, Tilo Muetze -- Marathon - The SQL Tool for Firebird & InterBase http://gmarathon.sourceforge.net |
From: Paul V. <pa...@vi...> - 2003-09-12 12:30:41
|
Hi Tilo, I found this note from you in the Changelog (20.02.2003): docs/images/callouts - directory removed, the callout images from DocBook XSL Stylsheet (docbook dir) are used But the dir and its contents are still there. Can they be removed, or are they in use again? (Doesn't look like it.) Greetings, Paul |
From: Paul V. <pa...@vi...> - 2003-09-12 11:37:27
|
Hello all, The CVS directory src\docs\firebirddocs\images is empty, but it is referenced twice in build.xml as a source to copy files from. As such, this is no problem, as long as the directory is there in the working copy. But if you checkout or update with the -P flag (as some frontends do by default), the empty directory won't be there and you get a build error later for the targets defaulthtml and printablehtml. If we think this dir will remain empty for awhile - or forever - it might be better to comment out those lines in build.xml, or even remove them. The images to be used for the HTML targets now live in src\docs\images Greetings, Paul Vinkenoog |
From: Paul V. <pa...@vi...> - 2003-09-11 13:48:30
|
Hello Tilo, >> 1. Unpack both zips, moving the contents to the right place... >> 2. Repack the troublemaking archive in such a way that... > 1. costs more time for us but it's easier for writers. Anyway I'm > still not convinced that unzipping make things that much complicated. Maybe not much, but it is an additional two steps to take. And you have to watch the target dirs while unpacking. I'd rather take those steps on our end once, than oblige each and every docwriter to take them on their end. > I still would go with 2., but you can decide because I don't have > time before mid Oct.. If you leave it up to me, I'll go for 1 in the next couple of days, unless there is some additional benefit (other than saving my own time) in leaving the zips in CVS. Greetings, Paul Vinkenoog |
From: Tilo M. <tm...@al...> - 2003-09-11 11:56:48
|
Hi, "Paul Vinkenoog" <pa...@vi...> schrieb im Newsbeitrag news:Pin...@so...... > Hello all - but especially Tilo this time, > > We still have those two zips in the CVS tree, and lots of obsolete > files and subdirs that should be replaced by the zip contents. One of > the zips also unpacks awkwardly, creating a subdir that shouldn't be > there at all. We can fix this in two ways: > > 1. Unpack both zips, moving the contents to the right place where > necessary, and commit to CVS. Obsolete files not overwritten by > content from the zips can be sent to the attic; obsolete subdirs > can either stay in place empty or we must have an admin ask SF to > remove them. > > 2. Repack the troublemaking archive in such a way that it unzips into > the right subdir, and leave the two zips in CVS. Move obsolete > stuff to attic and/or... same as above. 1. costs more time for us but it's easier for writers. Anyway I'm still not convinced that unzipping make things that much complicated. > Personally I have a strong preference for solution 1, because a) CVS > is a "text thing", and b) unzipping into CVS minimizes the extra steps > a body has to take after checking out the manual module. An additional > benefit is that if we upgrade the DocBook archives and we have things > unzipped in CVS, we can easily use cvs diff if problems arise, to see > what has changed, and how, and where. We can't do that with binaries. The most problems that arise while using a new Docbook and Java releases are related to the libraries (.jar). > However, I can live with solution 2 as well. But the present situation > makes things unnecessarily complicated. Agreed, at least the zip paths should be correct. > Tilo, what do you think is best? Whichever solution we choose, I > volunteer to do the work (or part of it); in fact it'll be a good > opportunity to see if my setup works, including committing. I still would go with 2., but you can decide because I don't have time before mid Oct.. > Another, smaller thing: Olivier Mascia's path fix should be applied, > for those who have Java in a path containing whitespace. I can do that > too if you like. Yes feel free to commit it. > After that, all we have to do is write those docs and we're done! :-) Easy one ;) > Greetings, > Paul Vinkenoog -- Regards, Tilo Muetze -- Marathon - The SQL Tool for Firebird & InterBase http://gmarathon.sourceforge.net |
From: Paul V. <pa...@vi...> - 2003-09-10 23:16:34
|
Hello all - but especially Tilo this time, We still have those two zips in the CVS tree, and lots of obsolete files and subdirs that should be replaced by the zip contents. One of the zips also unpacks awkwardly, creating a subdir that shouldn't be there at all. We can fix this in two ways: 1. Unpack both zips, moving the contents to the right place where necessary, and commit to CVS. Obsolete files not overwritten by content from the zips can be sent to the attic; obsolete subdirs can either stay in place empty or we must have an admin ask SF to remove them. 2. Repack the troublemaking archive in such a way that it unzips into the right subdir, and leave the two zips in CVS. Move obsolete stuff to attic and/or... same as above. Personally I have a strong preference for solution 1, because a) CVS is a "text thing", and b) unzipping into CVS minimizes the extra steps a body has to take after checking out the manual module. An additional benefit is that if we upgrade the DocBook archives and we have things unzipped in CVS, we can easily use cvs diff if problems arise, to see what has changed, and how, and where. We can't do that with binaries. However, I can live with solution 2 as well. But the present situation makes things unnecessarily complicated. Tilo, what do you think is best? Whichever solution we choose, I volunteer to do the work (or part of it); in fact it'll be a good opportunity to see if my setup works, including committing. Another, smaller thing: Olivier Mascia's path fix should be applied, for those who have Java in a path containing whitespace. I can do that too if you like. After that, all we have to do is write those docs and we're done! :-) Greetings, Paul Vinkenoog PS: "A body" is how Huckleberry Finn says "somebody" or "a person". It just came naturally with the flow of the sentence so I decided to let it stay there. Actually, I think it's really good English! |
From: Paul V. <pa...@vi...> - 2003-09-10 22:37:09
|
Hello all, This message is intended for everybody who is planning or considering to help with the Firebird docs. As said earlier, practically everything will have to be written from scratch. Helen Borrie, who has lots of experience with doc writing, advised us to develop a how-to on writing Firebird docs. I think this is a good idea, but I would like to know if there's anybody out there who's really going to write something in the next couple of months, and thinks this might be helpful. Or who would be willing to contribute to such a how-to, even if only by discussing here what should go in it. Or... is there anybody out there now saying "Yes, I'd like to help writing docs and I have the time too, but I need a place to start, I need guidelines or else I don't know how or where to begin" ? You see, no matter how good the idea is, it _is_ another document to write. Is it worth investing time in a howto at this stage if noone is going to write "real" docs anyway? Or if the few people who may start soon don't really feel they need one? Myself I wanted to start with the API documenation a month ago, but due to a lot of extra work I just didn't find the time. Hopefully things will be better soon, but I'll never have a _lot_ of time. That's why I want to spend my doc writing hours in the most effective way. Greetings, and good wheather upon you all, Paul Vinkenoog |
From: Robert (J. M. <rj...@ar...> - 2003-09-04 14:21:26
|
Herman Timmermans wrote: > Why not just writing the documentation in OpenOffice? > It is open source, multi-platform, you can produce PDF and RTF and DOC > formats as well, and the internal format is XML based (if I'm not > mistaking?) Because it is way too flexible, and the documentation will end up in a big mess. The documentation needs to be in a simple framework, with things like headings, SQL code snippets, other code snippets etc. identified clearly and consistently wherever they appear, so that when converting to other formats, they can remain consistent. Rules can then be enforced, like not having a title in the middle of a block of code. Diff and merge operations could be performed when people edit things, allowing different peoples ideas to be merged semi-automatically, which just couldn't be done with an office type package. Robert Munro |
From: Herman T. <tim...@sk...> - 2003-09-03 13:42:29
|
Paul Vinkenoog wrote: > Hi all, > > A number of people have expressed interest in helping with the docs > lately, so this might be a good time to discuss what kind of > documentation we would like to produce, and how we are going to set > things up. > > But first, if you are new to the Firebird Documentation subproject, > read this webpage if you haven't already done so; it contains a lot > of information about the tools you are going to need: > > http:// > firebird.sourceforge.net/index.php?op=devel&sub=doc&id=development > > Also follow the links in the section titled "Environment setup". > > NOTE: Do not yet checkout ("download") the manual module from the > Firebird CVS tree at SourceForge. In the current state the doc > building process doesn't work. Tilo fixed it, but it seems the > changes didn't make it to the CVS tree yet. > > (Well you can still checkout the module of course, to test your > CVS setup :-)) > > TIP: For XML editing, I prefer XMLMind because it really lets you > work with the *structure* of your document. Being Java-based, it > loads slowly and it also has one big drawback: it won't let you work > in source (flat text) mode. Still, I prefer it to the others I've > tested. The Standard Edition is free; you can find it at: > > http://www.xmlmind.com/xmleditor/ > Why not just writing the documentation in OpenOffice? It is open source, multi-platform, you can produce PDF and RTF and DOC formats as well, and the internal format is XML based (if I'm not mistaking?) Brgds, Herman -- Suse Linux Professional 8.1 on Athlon 1.1 Ghz 512 Mb Anti Spam = remove the "dot" and the "at" Registered Linux User #264690 |
From: Paul V. <pa...@vi...> - 2003-08-28 12:17:38
|
Hello kylixyao, This is weird: Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=3Dsc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 19sJJW-0001cC-00; Thu, 28 Aug 2003 02:43:34 -0700 Received: from [206.191.46.199] (helo=3Dnews.atkin.com) by sc8-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 19q6G4-0000Yn-00 for <fir...@li...>; Fri, 22 Aug 2003 00:22:53 -0700 Received: by news.atkin.com (Postfix, from userid 9) id EA63F8F46; Fri, 22 Aug 2003 03:18:23 -0400 (EDT) SourceForce kept your message "on hold" for 6 days before forwarding it to the list members. Strange... But regarding your question: please see the response to Germ=E1n I posted ten minutes ago. Greetings, Paul Vinkenoog |
From: Paul V. <pa...@vi...> - 2003-08-28 12:10:03
|
Hello Germ=E1n, > If you can build docs please send to me. Please read the recent messages on this list and you should be able to build them yourself. If not, post again telling what you have tried and where it went wrong. But be warned that we have very little so far! If you need documentation for your development work, the best you can do is go to www.ibphoenix.com --> Main Downloads, and get the Borland IB6 beta docs and the Firebird Quickstart Guide (both free). You can also buy CDs with the a good User Guide, a Reference Guide and lots more. Greetings, Paul Vinkenoog |