Re: [PHP-DOC] CVS <-> Online Manual
Great! Goba Curt Zirzow wrote: > On Mon, Nov 28, 2005 at 06:17:30PM +0100, Gabor Hojtsy wrote: > >>prebuilt one is the easiest to start with. If this software gets >>production ready, all the changes will be pushed to mirror sites in no >>time (hours!). We need actively helping people to make this exciting >>revolution happen :) >> >> http://blog.phpdoc.info/archives/18-Pre-Built-Livedocs.html > > > I finally got my dev server back up, with the tableless theme of > php.net [1] (still needs a few css fixes)I'm eager to get this > moving as well. > > [1] http://livedocs.zirzow.dyndns.org/ > > Curt.
Re: [PHP-DOC] CVS <-> Online Manual
On Mon, Nov 28, 2005 at 06:17:30PM +0100, Gabor Hojtsy wrote: > prebuilt one is the easiest to start with. If this software gets > production ready, all the changes will be pushed to mirror sites in no > time (hours!). We need actively helping people to make this exciting > revolution happen :) > > http://blog.phpdoc.info/archives/18-Pre-Built-Livedocs.html I finally got my dev server back up, with the tableless theme of php.net [1] (still needs a few css fixes)I'm eager to get this moving as well. [1] http://livedocs.zirzow.dyndns.org/ Curt. -- cat .signature: No such file or directory
Re: [PHP-DOC] CVS <-> Online Manual
>>- Doing a new build needs to rebuild the whole manual, regardless >> of the number of pages changed (10 is a drop in the ocean if >> you consider the thousands of pages in the manual) > > Well, I thought there was some possibility like the > $ xsltproc --stringparam rootid "" xsl/html.xsl manual.xml > mentioned in the dochowto. This is not possible, as one change in a file can in turn change much more output files (think indexes, table of contents in page sidebars, cross references, etc). The rootid hack is only relevant for testing purposes, when an overall broken manual is not really a problem. >>- Last but not least this works this way, because unfortunately >> those who complain about this system rarely end up >> improving/fixing/submitting bugs and patches against >> livedocs, so that we can get out of this situation. > > I see, so it all boils down on getting livedocs to production quality, > so the whole process of supplying the manual can be redone, do I get > this right? Yes, noone puts effort into improving our build situation as there is a great prospect on the horizon to replace the whole system. There is no point in improving a system which is on the way out. In fact that energy should be directed at the new shiny system under development. Goba
Re: [PHP-DOC] CVS <-> Online Manual
> - Doing failed builds are enough burden for the building machine. That is the type of answer I hoped for, though in a positive way. But at least it's statement regarding the (lacking) possibility. OK, that's sad > - Doing a new build needs to rebuild the whole manual, regardless > of the number of pages changed (10 is a drop in the ocean if > you consider the thousands of pages in the manual) Well, I thought there was some possibility like the $ xsltproc --stringparam rootid "" xsl/html.xsl manual.xml mentioned in the dochowto. > > - Last but not least this works this way, because unfortunately > those who complain about this system rarely end up > improving/fixing/submitting bugs and patches against > livedocs, so that we can get out of this situation. I see, so it all boils down on getting livedocs to production quality, so the whole process of supplying the manual can be redone, do I get this right? OK, so I thank you very much for your answers. Though they were not very satisfying for my "problems", but I am now quite enlightened compared to before :) Bye, Florian
Re: [PHP-DOC] CVS <-> Online Manual
> We need actively helping people to make this exciting > revolution happen :) *cough* Derick's on vacation. (hopefully that excuse will work.. (-: ) I'll try to make it happen.. S
Re: [PHP-DOC] CVS <-> Online Manual
>>Run a 'make test' on the German manual. If it runs fine, and you see >>quite a lot of changes needing attention, bug Derick to build the German >>translation. If you are unhappy with this situation, try livedocs. > > Hello Gabor, > that's exactly my point. I don't need to check them for myself and I > don't translate them because I need them in German. I have livedocs > running on my local box to test it. If I couldn't read the english > originals, I wouldn't have translated them ;) > Why do we need to manually do this (especially mail Derick about it, and > then mail again multiple times if it didn't work like this time). This > has been like this since I started, always behind - my main question > was, why that isn't automated, when, say 10 commits have been made or 2 > weeks are gone? - Doing failed builds are enough burden for the building machine. - Doing a new build needs to rebuild the whole manual, regardless of the number of pages changed (10 is a drop in the ocean if you consider the thousands of pages in the manual) - Pushing up the new files to the rsync server, all are going to have new creation dates associated with them, meaning that the rsync processes will not know right away, that files are not changed, so the whole build needs to be checked for changes, when mirrors (including php.net) get the new files, resulting in increased traffic and load on the rsync server (consider the 120 official, and countless unofficial mirrors) - Last but not least this works this way, because unfortunately those who complain about this system rarely end up improving/fixing/submitting bugs and patches against livedocs, so that we can get out of this situation. Goba
Re: [PHP-DOC] CVS <-> Online Manual
Florian Anderiasch wrote: Hi Florian, > Hello there, > I've got a few things to say that bug me about building new versions of > the localized manual. I can only speak about the German translation, > because that's where I've done a bit of work lately. > > The online manual at http://de.php.net/ shows "Last updated: > Tue, 20 Sep 2005" and as I follow the commit-messages quite a bit has > been done in that time. > > Now I've heard that some days ago Derick started the build process, and > http://doc.php.net/php/de/revcheck.php seems to be up to date, but the > docs themselves haven't changed. > Derick's on holiday so I have no idea when he will be back. We used to get build logs on some php.net URL but I can't remember which URL it was. Ideally what we need is to do weekly builds per language over a weekend using multiple machines to make the builds take quicker :) > I may have done something wrong with de/reference/pdo/reference.xml for > example, but even the other changes didn't show up. > The revcheck script runs on a daily basis, checking out from CVS and updating sqlite databases on my one server. > Now the question is: Why is the manual always several months behind, > when the stuff already *is* available. I know that this DocBook stuff > takes ages to process, but would it be too much to at least run it every > 2 weeks? I count 11 commits to de/ in the last 10 days alone, that are > certainly ~15 updated pages. > There is a project called 'livedocs' in progress to make manual pages available in a faster fashion without having to rebuild the doc book stuff. > I'm sorry if I'm bugging the wrong people, but the doc-de list isn't > really active and I doubt that anyone there can give me details or even > check this update (that should've been completed after a few days..) > We need people to help improve the way we build docs from the current build the doc book stuff to almost real time with live docs! Regards --jm > Greetings, > Florian - Jacques Marneweck http://www.powertrip.co.za/blog/
Re: [PHP-DOC] CVS <-> Online Manual
> Run a 'make test' on the German manual. If it runs fine, and you see > quite a lot of changes needing attention, bug Derick to build the German > translation. If you are unhappy with this situation, try livedocs. Hello Gabor, that's exactly my point. I don't need to check them for myself and I don't translate them because I need them in German. I have livedocs running on my local box to test it. If I couldn't read the english originals, I wouldn't have translated them ;) Why do we need to manually do this (especially mail Derick about it, and then mail again multiple times if it didn't work like this time). This has been like this since I started, always behind - my main question was, why that isn't automated, when, say 10 commits have been made or 2 weeks are gone? Greetings, Florian
