On Sun, 13 Dec 2009 17:23:22 -0800, Philip Olson <phi...@roshambo.org>
wrote: > 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? Noted. I will implemente this today. > 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? Noted. I will review it. > >> * 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? Last tonight, I will totaly re-wrote the way we get summray information for the main page. I'm actually on a testing stage and I will be able to commit all this change this tonight. Actually, when we display for the first time the application, a "big" Sql query is done to find the summary information, cause the query take over than 30 secondes (and failed to load the data). In my dev. repository, this data is came back from a single line into DB, and so, the query is done very quickly. All this summary information are generated when we update the data (via the cron job, or via the Main Menu). I have work again this query and delete "old" and "critical" files (this notion came from the old revcheck script and are not so useful) witch use an JOIN query. Now, we only have informations about "Files Need translates", "Stale Files" & "Uptodate files". All of this cause big change into the code, but less into the DB structure. > >> * 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. Actually, I store into DB the last logging for one user. This information is not display anywhere in the UI. If you find a way to present this information, tell me ;) About the ExtJs 3.0 migration, when I finish all I have in mind, and when I finish all of your (futur) feedback, I will start it. I will inform you to update the online version and so, follow this migration. Best, Yannick > Regards, > Philip
