On Dec 10, 2009, at 9:31 AM, yannick wrote: > Hi Philip, > > The documentation editor is about to be available for production purpose.
Excellent! So essentially this means people here should now test the editor. I don't think we should call for public use yet (from the world) but people here should use and attempt to break things with the system, and report/fix bugs. The one open bug (#50193) appears to be a show stopper. And Yannick wrote plenty of documentation here: - http://wiki.php.net/doc/editor > There are always a few issus with it : > > * When an anonymous user edit a new file from a folder witch doesn't exist > into > his language, the editor try to commit this new folder. I must find a > solution > with this case. > @me : I will work on it soon. > * The perm link is now Ok, but there is a little issue when we display it > into > the editor and when the file contains multiple xml:id from DB. We must to > display only the first. Normally, when we query the editor with a link like : > http://doc.php.net/editor/?perm=fr/function.date-create-from-format.php > @Kschan : Can you work on this ? After your exam, of course ;) (good luck > with > it !!) > @Hannes : Can you start a patch for phD to add a link like this into the > documentation ? Near all xml:id should be fine ;) With it, we can start to > debug our perm link. > > I have some ideas and I want to now what do you thinks about its : > > * The checkBuild processus : There is a cron job to check all build. The > result is actually display in a simple grid : "Main Menu" => "EN tools" => > "Check Build". I have commit a patch to erase all data before start a new > check. Can we must conserve this data or not ? How much check did we stock ? Logging and history is great but certainly not required. I'm unsure what you mean by a "simple grid" as I see simply see configure.php output. We could probably only store failed builds, for let's say a month? And while testing it appears "--enable-xml-details" is used regardless of it being selected or not. Considering the amount of resources this single option requires, I wonder if we should allow it at all. Maybe disable for anonymous users? > * I want to start the migration to ExtJs 3.0. I have test it and there is not > so much things to change to be ready with this version. > The UI is much faster with it and the great things is about graph generation > (see this > > http://www.extjs.com/deploy/dev/examples/chart/charts.html > > to replace the graph on the main page) > > Did we wait after the first production of this app with ExtJs 2.X before > start > the migration to ExtJs 3.0 ? We can start testing, but we may as well have ExtJs 3 working before entering public use. Any optimization/speed we can find the better, as the editor appears to require plenty of resources. A few weeks ago I notice it spiked MySQL usage past 100% CPU, so perhaps database usage can be considered the bottleneck. Let's do more testing later when we get around 3-6 people using it simultaneously via an IRC party. The more activity logging the better (like for queries), does it do any now? > * Actually, when a user use the editor and commit a file, we don't log > anythings. Perhaps we must log each commit to produice statistic later on the > use of this app ? Logging usage would be interesting. Regards, Philip
