On Sunday, February 17, 2013 at 10:56 PM, Tim Starling wrote:
On 16/02/13 07:55, Steven Walling wrote:
I didn't see it in the docs above, so thought I'd ask... Is this going to include rollout of the CodeEditor extension, or will that be done separately?
CodeEditor will be enabled, but with $wgCodeEditorEnableCore = false, i.e. in the Module namespace only, not in the MediaWiki namespace. This is the same way we deployed it to mediawiki.org (http://mediawiki.org)
As I said to Ori when he asked me about this: I'm fine with it being deployed with $wgCodeEditorEnableCore = true, I just don't want to have to project manage it, since large JS apps are not the sort of thing I usually do. With $wgCodeEditorEnableCore = true, it's a fairly disruptive extension, so it would be good to have someone handling community notifications and bug reports.
I'm interested in seeing this through (= enabling CodeEditor on MediaWiki NS), but I need a bit more time with the extension first so I can size up how much ongoing work it will require. There's already a bug asking for it to be deployed: https://bugzilla.wikimedia.org/show_bug.cgi?id=39654. I propose we (meaning anyone interested in this deployment, Tim exempted per above) track progress there.
This is exciting! Do we have plans for further measurement when it comes to Lua's impact on page load times/publishing any results so far? In addition to the general benefit of not having to program using wikitext/parser functions, I seem to remember the performance improvements being the big selling point of Scribunto.
It will be possible to gather some retrospective data from slow-parse.log.
To expand a little: slow-parse.log is a log file on fluorine (accessible to users with shell; the file is in /a/mw-log) that gets an entry every time an article takes more than three seconds to render. Each entry looks like this:
2013-02-18 12:55:18 mw1058 enwiki: 4.25 War_of_the_First_Coalition
The fields are (from left to right) current date, current time, host, wiki, rendering time, title.
We have six months' worth of logs, broken down by calendar day, in /a/mw-log/archive. The oldest is 2012-08-22. (we may have older files on tape backup). Log files are about 14-15 MB, gzipped. Six months' worth is 2.4 GB.
If this information were made more visible, it could give editors a palpable sense of accomplishment as expensive templates are ported to lua. I don't think the logs contain any sensitive data, so it should be doable to set up an rsync job to sync them to labs and thus make them available for people to analyze and visualize. Would anyone be interested in that? (I'm CCing the analytics list as well.)
As Rob notes, deployment of lua is not by itself expected to have an impact on rendering time; rather, it is the porting of templates to use it that will speed things up. The full picture will only emerge in the weeks / months + following deployment.
Anyways, I'm pretty excited about this. It's a big change. Congrats to all involved.
-Ori
Great idea ori! I can get the data rsynced to dumps.wikimedia.org for download Is that a good place? D
Sent from my iPhone
On 2013-02-18, at 8:32, Ori Livneh ori@wikimedia.org wrote:
On Sunday, February 17, 2013 at 10:56 PM, Tim Starling wrote:
On 16/02/13 07:55, Steven Walling wrote:
I didn't see it in the docs above, so thought I'd ask... Is this going to include rollout of the CodeEditor extension, or will that be done separately?
CodeEditor will be enabled, but with $wgCodeEditorEnableCore = false, i.e. in the Module namespace only, not in the MediaWiki namespace. This is the same way we deployed it to mediawiki.org
As I said to Ori when he asked me about this: I'm fine with it being deployed with $wgCodeEditorEnableCore = true, I just don't want to have to project manage it, since large JS apps are not the sort of thing I usually do. With $wgCodeEditorEnableCore = true, it's a fairly disruptive extension, so it would be good to have someone handling community notifications and bug reports.
I'm interested in seeing this through (= enabling CodeEditor on MediaWiki NS), but I need a bit more time with the extension first so I can size up how much ongoing work it will require. There's already a bug asking for it to be deployed: https://bugzilla.wikimedia.org/show_bug.cgi?id=39654. I propose we (meaning anyone interested in this deployment, Tim exempted per above) track progress there.
This is exciting! Do we have plans for further measurement when it comes to Lua's impact on page load times/publishing any results so far? In addition to the general benefit of not having to program using wikitext/parser functions, I seem to remember the performance improvements being the big selling point of Scribunto.
It will be possible to gather some retrospective data from slow-parse.log.
To expand a little: slow-parse.log is a log file on fluorine (accessible to users with shell; the file is in /a/mw-log) that gets an entry every time an article takes more than three seconds to render. Each entry looks like this:
2013-02-18 12:55:18 mw1058 enwiki: 4.25 War_of_the_First_Coalition
The fields are (from left to right) current date, current time, host, wiki, rendering time, title.
We have six months' worth of logs, broken down by calendar day, in /a/mw-log/archive. The oldest is 2012-08-22. (we may have older files on tape backup). Log files are about 14-15 MB, gzipped. Six months' worth is 2.4 GB.
If this information were made more visible, it could give editors a palpable sense of accomplishment as expensive templates are ported to lua. I don't think the logs contain any sensitive data, so it should be doable to set up an rsync job to sync them to labs and thus make them available for people to analyze and visualize. Would anyone be interested in that? (I'm CCing the analytics list as well.)
As Rob notes, deployment of lua is not by itself expected to have an impact on rendering time; rather, it is the porting of templates to use it that will speed things up. The full picture will only emerge in the weeks / months + following deployment.
Anyways, I'm pretty excited about this. It's a big change. Congrats to all involved.
-Ori _______________________________________________ Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
If you please: https://gerrit.wikimedia.org/r/#/c/49678/
If you don't please: hokay!
On Feb 18, 2013, at 10:00 AM, Diederik van Liere dvanliere@wikimedia.org wrote:
Great idea ori! I can get the data rsynced to dumps.wikimedia.org for download Is that a good place? D
Sent from my iPhone
On 2013-02-18, at 8:32, Ori Livneh ori@wikimedia.org wrote:
On Sunday, February 17, 2013 at 10:56 PM, Tim Starling wrote:
On 16/02/13 07:55, Steven Walling wrote:
I didn't see it in the docs above, so thought I'd ask... Is this going to include rollout of the CodeEditor extension, or will that be done separately?
CodeEditor will be enabled, but with $wgCodeEditorEnableCore = false, i.e. in the Module namespace only, not in the MediaWiki namespace. This is the same way we deployed it to mediawiki.org
As I said to Ori when he asked me about this: I'm fine with it being deployed with $wgCodeEditorEnableCore = true, I just don't want to have to project manage it, since large JS apps are not the sort of thing I usually do. With $wgCodeEditorEnableCore = true, it's a fairly disruptive extension, so it would be good to have someone handling community notifications and bug reports.
I'm interested in seeing this through (= enabling CodeEditor on MediaWiki NS), but I need a bit more time with the extension first so I can size up how much ongoing work it will require. There's already a bug asking for it to be deployed: https://bugzilla.wikimedia.org/show_bug.cgi?id=39654. I propose we (meaning anyone interested in this deployment, Tim exempted per above) track progress there.
This is exciting! Do we have plans for further measurement when it comes to Lua's impact on page load times/publishing any results so far? In addition to the general benefit of not having to program using wikitext/parser functions, I seem to remember the performance improvements being the big selling point of Scribunto.
It will be possible to gather some retrospective data from slow-parse.log.
To expand a little: slow-parse.log is a log file on fluorine (accessible to users with shell; the file is in /a/mw-log) that gets an entry every time an article takes more than three seconds to render. Each entry looks like this:
2013-02-18 12:55:18 mw1058 enwiki: 4.25 War_of_the_First_Coalition
The fields are (from left to right) current date, current time, host, wiki, rendering time, title.
We have six months' worth of logs, broken down by calendar day, in /a/mw-log/archive. The oldest is 2012-08-22. (we may have older files on tape backup). Log files are about 14-15 MB, gzipped. Six months' worth is 2.4 GB.
If this information were made more visible, it could give editors a palpable sense of accomplishment as expensive templates are ported to lua. I don't think the logs contain any sensitive data, so it should be doable to set up an rsync job to sync them to labs and thus make them available for people to analyze and visualize. Would anyone be interested in that? (I'm CCing the analytics list as well.)
As Rob notes, deployment of lua is not by itself expected to have an impact on rendering time; rather, it is the porting of templates to use it that will speed things up. The full picture will only emerge in the weeks / months + following deployment.
Anyways, I'm pretty excited about this. It's a big change. Congrats to all involved.
-Ori _______________________________________________ Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics