[Wikitech-l] New branch testing in operations/mediawiki-config
Can we create a new branch which would be speedily merged when changes were done to it, so that we could check out on labs and apply the change there in order to test if patches submitted by devs works ok? Thanks to Antoine we use the same repository on beta project, but right now it's really hard to test stuff submitted to gerrit because we need to merge stuff by hand. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New branch testing in operations/mediawiki-config
On Fri, Jun 29, 2012 at 6:58 AM, Petr Bena benap...@gmail.com wrote: Can we create a new branch which would be speedily merged when changes were done to it, so that we could check out on labs and apply the change there in order to test if patches submitted by devs works ok? Thanks to Antoine we use the same repository on beta project, but right now it's really hard to test stuff submitted to gerrit because we need to merge stuff by hand. I don't see any problem with this really, as long as the branches don't get wildly out of sync like the puppet repo did. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New branch testing in operations/mediawiki-config
On Jun 29, 2012, at 1:04 PM, Chad wrote: On Fri, Jun 29, 2012 at 6:58 AM, Petr Bena benap...@gmail.com wrote: Can we create a new branch which would be speedily merged when changes were done to it, so that we could check out on labs and apply the change there in order to test if patches submitted by devs works ok? Thanks to Antoine we use the same repository on beta project, but right now it's really hard to test stuff submitted to gerrit because we need to merge stuff by hand. I don't see any problem with this really, as long as the branches don't get wildly out of sync like the puppet repo did. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Note that one can also use git-review in labs (if not, lets install it then). I'm not sure if this sounds crazy, but you could do git review -d 1234 and test it that way. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New branch testing in operations/mediawiki-config
Yes but that would probably overwrite any previous tests On Fri, Jun 29, 2012 at 1:23 PM, Krinkle krinklem...@gmail.com wrote: On Jun 29, 2012, at 1:04 PM, Chad wrote: On Fri, Jun 29, 2012 at 6:58 AM, Petr Bena benap...@gmail.com wrote: Can we create a new branch which would be speedily merged when changes were done to it, so that we could check out on labs and apply the change there in order to test if patches submitted by devs works ok? Thanks to Antoine we use the same repository on beta project, but right now it's really hard to test stuff submitted to gerrit because we need to merge stuff by hand. I don't see any problem with this really, as long as the branches don't get wildly out of sync like the puppet repo did. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Note that one can also use git-review in labs (if not, lets install it then). I'm not sure if this sounds crazy, but you could do git review -d 1234 and test it that way. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New branch testing in operations/mediawiki-config
Current idea: someone submit a config change this change is merged to testing branch we git pull on labs people test if change works ok and submit review to gerrit we merge to master branch or reject it On Fri, Jun 29, 2012 at 2:07 PM, Petr Bena benap...@gmail.com wrote: Yes but that would probably overwrite any previous tests On Fri, Jun 29, 2012 at 1:23 PM, Krinkle krinklem...@gmail.com wrote: On Jun 29, 2012, at 1:04 PM, Chad wrote: On Fri, Jun 29, 2012 at 6:58 AM, Petr Bena benap...@gmail.com wrote: Can we create a new branch which would be speedily merged when changes were done to it, so that we could check out on labs and apply the change there in order to test if patches submitted by devs works ok? Thanks to Antoine we use the same repository on beta project, but right now it's really hard to test stuff submitted to gerrit because we need to merge stuff by hand. I don't see any problem with this really, as long as the branches don't get wildly out of sync like the puppet repo did. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Note that one can also use git-review in labs (if not, lets install it then). I'm not sure if this sounds crazy, but you could do git review -d 1234 and test it that way. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New branch testing in operations/mediawiki-config
On Jun 29, 2012, at 2:11 PM, Petr Bena wrote: Current idea: someone submit a config change this change is merged to testing branch we git pull on labs people test if change works ok and submit review to gerrit we merge to master branch or reject it On Fri, Jun 29, 2012 at 2:07 PM, Petr Bena benap...@gmail.com wrote: Yes but that would probably overwrite any previous tests No, git-review checks out the the remote ref/changeset in a local branch, preserving the proper context/history of that change set. These branches are not removed or overwritten. It does mean, however, that you can't randomly stack different tests upon eachother, but that's a good thing and avoids common errors. Herein lies also immediately the advantage: If a series of commits is submitted that depend on eachother, git-review'ing the top one will give you all, just like in mediawiki/core.git. Because we'd checkout a commit pointer with its parent tree, not a single commit on top of the previous test state (which what a testing branch would enforce). And it saves maintenance by not having to continously reset test to master – after (re-)submission and merging it for the second time. I'm not (yet) very active in the beta project on labs, but I imagine it would make sense not to introduce an neccecary double-review process here. They are in gerrit pending merge to master, and they can be checked out on labs as it is, that's a main feature of git-review. And afterwards checkout master again and leave your comments on gerrit and/or review, merge it. I'm not a big fan of Gerrit's overal design, but one the great aspects is that each change proposal is a branch by design. So in a way, every time a merge request is pushed to gerrit, you've got a branch new testing branch ready to be checked out. I agree with Chad, there is no problem with an actual testing branch, but if we can avoid it with an (what could be) a better workflow with less overhead of rebasing, dependency manipulation and double-merging etc. then.. -- Krinkle On Fri, Jun 29, 2012 at 1:23 PM, Krinkle krinklem...@gmail.com wrote: On Jun 29, 2012, at 1:04 PM, Chad wrote: On Fri, Jun 29, 2012 at 6:58 AM, Petr Bena benap...@gmail.com wrote: Can we create a new branch which would be speedily merged when changes were done to it, so that we could check out on labs and apply the change there in order to test if patches submitted by devs works ok? Thanks to Antoine we use the same repository on beta project, but right now it's really hard to test stuff submitted to gerrit because we need to merge stuff by hand. I don't see any problem with this really, as long as the branches don't get wildly out of sync like the puppet repo did. -Chad Note that one can also use git-review in labs (if not, lets install it then). I'm not sure if this sounds crazy, but you could do git review -d 1234 and test it that way. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New branch testing in operations/mediawiki-config
If we are testing multiple items in same moment, replacing one test with another is actually problem. That's what we need to somehow merge right now. I hoped that gerrit could do it for us. And we test multiple items there almost all time :) On Fri, Jun 29, 2012 at 2:22 PM, Krinkle krinklem...@gmail.com wrote: On Jun 29, 2012, at 2:11 PM, Petr Bena wrote: Current idea: someone submit a config change this change is merged to testing branch we git pull on labs people test if change works ok and submit review to gerrit we merge to master branch or reject it On Fri, Jun 29, 2012 at 2:07 PM, Petr Bena benap...@gmail.com wrote: Yes but that would probably overwrite any previous tests No, git-review checks out the the remote ref/changeset in a local branch, preserving the proper context/history of that change set. These branches are not removed or overwritten. It does mean, however, that you can't randomly stack different tests upon eachother, but that's a good thing and avoids common errors. Herein lies also immediately the advantage: If a series of commits is submitted that depend on eachother, git-review'ing the top one will give you all, just like in mediawiki/core.git. Because we'd checkout a commit pointer with its parent tree, not a single commit on top of the previous test state (which what a testing branch would enforce). And it saves maintenance by not having to continously reset test to master – after (re-)submission and merging it for the second time. I'm not (yet) very active in the beta project on labs, but I imagine it would make sense not to introduce an neccecary double-review process here. They are in gerrit pending merge to master, and they can be checked out on labs as it is, that's a main feature of git-review. And afterwards checkout master again and leave your comments on gerrit and/or review, merge it. I'm not a big fan of Gerrit's overal design, but one the great aspects is that each change proposal is a branch by design. So in a way, every time a merge request is pushed to gerrit, you've got a branch new testing branch ready to be checked out. I agree with Chad, there is no problem with an actual testing branch, but if we can avoid it with an (what could be) a better workflow with less overhead of rebasing, dependency manipulation and double-merging etc. then.. -- Krinkle On Fri, Jun 29, 2012 at 1:23 PM, Krinkle krinklem...@gmail.com wrote: On Jun 29, 2012, at 1:04 PM, Chad wrote: On Fri, Jun 29, 2012 at 6:58 AM, Petr Bena benap...@gmail.com wrote: Can we create a new branch which would be speedily merged when changes were done to it, so that we could check out on labs and apply the change there in order to test if patches submitted by devs works ok? Thanks to Antoine we use the same repository on beta project, but right now it's really hard to test stuff submitted to gerrit because we need to merge stuff by hand. I don't see any problem with this really, as long as the branches don't get wildly out of sync like the puppet repo did. -Chad Note that one can also use git-review in labs (if not, lets install it then). I'm not sure if this sounds crazy, but you could do git review -d 1234 and test it that way. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New branch testing in operations/mediawiki-config
Imagine: Some guy wants to deploy extension to Jamaican wikiversity and test it on labs for 2 months before deploying to production. He create a patch of config files and submit to gerrit. We merge it to test and extension is immediately deployed on beta. Another guy wants to test configuration change of Korean wikisource, he submit a patch, we merge it to test and he can test it on labs. Both tests are running together. Once any of tests are over, we can merge them to master. This isn't possible with gerrit-review, or I don't know how On Fri, Jun 29, 2012 at 2:28 PM, Petr Bena benap...@gmail.com wrote: If we are testing multiple items in same moment, replacing one test with another is actually problem. That's what we need to somehow merge right now. I hoped that gerrit could do it for us. And we test multiple items there almost all time :) On Fri, Jun 29, 2012 at 2:22 PM, Krinkle krinklem...@gmail.com wrote: On Jun 29, 2012, at 2:11 PM, Petr Bena wrote: Current idea: someone submit a config change this change is merged to testing branch we git pull on labs people test if change works ok and submit review to gerrit we merge to master branch or reject it On Fri, Jun 29, 2012 at 2:07 PM, Petr Bena benap...@gmail.com wrote: Yes but that would probably overwrite any previous tests No, git-review checks out the the remote ref/changeset in a local branch, preserving the proper context/history of that change set. These branches are not removed or overwritten. It does mean, however, that you can't randomly stack different tests upon eachother, but that's a good thing and avoids common errors. Herein lies also immediately the advantage: If a series of commits is submitted that depend on eachother, git-review'ing the top one will give you all, just like in mediawiki/core.git. Because we'd checkout a commit pointer with its parent tree, not a single commit on top of the previous test state (which what a testing branch would enforce). And it saves maintenance by not having to continously reset test to master – after (re-)submission and merging it for the second time. I'm not (yet) very active in the beta project on labs, but I imagine it would make sense not to introduce an neccecary double-review process here. They are in gerrit pending merge to master, and they can be checked out on labs as it is, that's a main feature of git-review. And afterwards checkout master again and leave your comments on gerrit and/or review, merge it. I'm not a big fan of Gerrit's overal design, but one the great aspects is that each change proposal is a branch by design. So in a way, every time a merge request is pushed to gerrit, you've got a branch new testing branch ready to be checked out. I agree with Chad, there is no problem with an actual testing branch, but if we can avoid it with an (what could be) a better workflow with less overhead of rebasing, dependency manipulation and double-merging etc. then.. -- Krinkle On Fri, Jun 29, 2012 at 1:23 PM, Krinkle krinklem...@gmail.com wrote: On Jun 29, 2012, at 1:04 PM, Chad wrote: On Fri, Jun 29, 2012 at 6:58 AM, Petr Bena benap...@gmail.com wrote: Can we create a new branch which would be speedily merged when changes were done to it, so that we could check out on labs and apply the change there in order to test if patches submitted by devs works ok? Thanks to Antoine we use the same repository on beta project, but right now it's really hard to test stuff submitted to gerrit because we need to merge stuff by hand. I don't see any problem with this really, as long as the branches don't get wildly out of sync like the puppet repo did. -Chad Note that one can also use git-review in labs (if not, lets install it then). I'm not sure if this sounds crazy, but you could do git review -d 1234 and test it that way. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making language selection sticky
Just stumbled over the GetLocalURL::Internal (http://www.mediawiki.org/wiki/Manual:Hooks/GetLocalURL::Internal) hook which was introduced in MW 1.19. This works pretty fine, just doesn't work for page content but that can be done with the linker. It works for pretty much everything else though, e.g. sites nav and tabs on top of the page. I am not sure though whether this is breaking anything. Putting it in there is pretty deep, so whenever an url is requested from any title object, the uselang parameter is attached to it. Seems to work fine so far. Cheers Daniel W. 2012/6/27 Platonides platoni...@gmail.com: On 27/06/12 11:43, Denny Vrandečić wrote: 2012/6/26 Platonides platoni...@gmail.com: On 26/06/12 18:48, Denny Vrandečić wrote: We tried to change the linker in order to add the uselang parameter every time -- but it only works in the content, not in the sidebar and actionlinks. We could put the language into a cookie, as the ULS currently does, but this means that the squid caches won't work, afaik. You are going to fragment the caches whether you use a parameter or a cookie. IMHO the cookie option is a cleaner one (I think that would also allow to make a single purge). We thought about using the uselang only if it is not the main used language (i.e., usually en), which means the caches would kick in 40% of the time at least. You mean serving other language directly from the apaches? Could be done. But would they support a 50% of the squid load? The cookie thing wouldn't have such a convenient default AFAIK, but I might be really easily wrong here. I think it could be done both ways. If the page is cacheable, the squid/varnish would store the page with the cookie value, and then serve it only for those request with the same cookie value. We could take the output just before it is send to the browser and regex-substitute all the links in order to add the uselang parameter every... OK, half joking. Only half. Some wikis have a javascript which does exactly that, adding a userlang parameter the moment you click a link. Much better than a string regex :) But only working if JavaScript is available. Sure, that's the limitation :) You would still cover almost everyone but jidanni ;) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Daniel Werner Software Engineer Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 26-0 http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New branch testing in operations/mediawiki-config
Petr Bena wrote: Can we create a new branch which would be speedily merged when changes were done to it, so that we could check out on labs and apply the change there in order to test if patches submitted by devs works ok? Thanks to Antoine we use the same repository on beta project, but right now it's really hard to test stuff submitted to gerrit because we need to merge stuff by hand. I will really prefer we avoid using a test branch. That is mainly based out of the experience of operations/puppet.git and I am not volunteering to maintain them in sync (will do if the community wants though). The current way is to put labs stuff in the -wmflabs.php files. We might want to rewrite our actual system to avoid the multiple conditional statement which are cluetering the files and just have one or two statement in the entry file (CommonSettings.php). Timo proposed a system where we would have a common configuration directory, one for production and another one for labs. Much like how /etc/php5/ is organized on Debian systems: /etc/php5/conf.d/ -- common conf /etc/php5/apache2 -- conf while running under web server /etc/php5/cli -- conf for CLI scripts Then each directory contains an ini file per extension. Regarding branches, I am fine having people maintain their own branch which they will be individually responsible for keeping it up to date. The thing is that Gerrit does not work that way and people are supposed to send patches. So they can maintain their own fork in a local branch which can be submitted to Gerrit. Their local branch will become a topic branch of our master. Then we can review / merge. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New branch testing in operations/mediawiki-config
But that's a lot of hand work, if we really do this, we won't use gerrit at all, we just copy paste code from diffs by hand and insert it to some extra files. I would rather volunteer to sync branches rather than this creep work. On Fri, Jun 29, 2012 at 4:22 PM, Antoine Musso hashar+...@free.fr wrote: Petr Bena wrote: Can we create a new branch which would be speedily merged when changes were done to it, so that we could check out on labs and apply the change there in order to test if patches submitted by devs works ok? Thanks to Antoine we use the same repository on beta project, but right now it's really hard to test stuff submitted to gerrit because we need to merge stuff by hand. I will really prefer we avoid using a test branch. That is mainly based out of the experience of operations/puppet.git and I am not volunteering to maintain them in sync (will do if the community wants though). The current way is to put labs stuff in the -wmflabs.php files. We might want to rewrite our actual system to avoid the multiple conditional statement which are cluetering the files and just have one or two statement in the entry file (CommonSettings.php). Timo proposed a system where we would have a common configuration directory, one for production and another one for labs. Much like how /etc/php5/ is organized on Debian systems: /etc/php5/conf.d/ -- common conf /etc/php5/apache2 -- conf while running under web server /etc/php5/cli -- conf for CLI scripts Then each directory contains an ini file per extension. Regarding branches, I am fine having people maintain their own branch which they will be individually responsible for keeping it up to date. The thing is that Gerrit does not work that way and people are supposed to send patches. So they can maintain their own fork in a local branch which can be submitted to Gerrit. Their local branch will become a topic branch of our master. Then we can review / merge. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New branch testing in operations/mediawiki-config
On Fri, Jun 29, 2012 at 3:58 AM, Petr Bena benap...@gmail.com wrote: Can we create a new branch which would be speedily merged when changes were done to it, so that we could check out on labs and apply the change there in order to test if patches submitted by devs works ok? Thanks to Antoine we use the same repository on beta project, but right now it's really hard to test stuff submitted to gerrit because we need to merge stuff by hand. I think we need to keep beta labs reasonably close to near production state. We made an exception for Timed Media Handler, but generally speaking, we want to have an environment that doesn't have a lot of experimental stuff. If we mix up a lot of different people's experiemental stuff there, then it will diminish the value of the bug reports that come out there. Here's my thoughts on what we should be doing there: * Always stay up to the very latest version of master, preferably automatically * Only deploy extensions which have a scheduled release window[1] * For items that are a little more experimental in nature, we should deploy new feature wikis in the beta cluster. (e.g. crazyfeature.beta.wmflabs.org ). Note, these still need to run on the same codebase, so anything needed by crazyfeature needs to be in master, guarded by a runtime feature flag if necessary Given how hard it has been to keep beta labs in any sort of functional state, encouraging unreviewed and experimental code moves this from beta to alpha, and makes it pretty much useless for the type of integration testing that we need to do. Note, even as we speak, the beta.wmflabs.org redirect points to a non-existent instance. Petr, I'm a little alarmed by this statement: we need to merge stuff by hand. What do you mean by merging by hand, and what sorts of things are you merging? Rob [1] http://wikitech.wikimedia.org/view/Software_deployments ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Technical hurdles for enabling $wgHtml5 on Wikimedia sites?
Hi Helder, Thanks for posting this to VPT, and relaying things back here. Comments inline... On Thu, Jun 28, 2012 at 5:26 PM, Helder . helder.w...@gmail.com wrote: Anomie pointed out on enwiki's Village Pump[1] the problem with the Cite extension mentioned on https://bugzilla.wikimedia.org/show_bug.cgi?id=27478#c12 I'm not sure. I replied on VPT though. It would be great if someone could repro this problem on test2, and then, if its still a problem, file a separate bug. Will $wgExperimentalHtmlIds be set to false? How is it configured on mw.org? Doesn't seem to be explicitly mentioned in our site config, so I think this is false. Rob [1] http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#HTML5_is_comming_.28again.29 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Announcement: Matt Walker joins Wikimedia as Fundraising Engineer
Hello everyone, It’s with great pleasure that I’m announcing that Matt Walker has joined the Wikimedia Foundation as a Fundraising Engineer. Before joining us, Matt was a software engineer at Rockwell Collins Control Technologies developing “a DO-178B level A qualified Real-Time Operating System in C and PowerPC assembly.” (Ask him about it.) He got his dual B.S. in EE and CS from the University of Tulsa with a minor in Mathematics. On the side, Matt enjoys tech theatre, glass blowing, SCUBA diving, hiking, and bicycling so I’m not sure how he’ll fit in with his move to the Bay Area. During the reference check, the department chair of Electrical Engineering at his uni regaled me with stories about a time lapse video project he self-started and having to sign a permission slip for a high school prom. His first official day will be on July 9th assuming he survives his cross-country trip through Wyoming and the Dakotas. (I’ve seen the trailers for Longmire http://en.wikipedia.org/wiki/Longmire_(TV_series) so it’s not a given — Wyoming sounds like a very dangerous place.) He will be working with the FR-Tech team trying to establish the lower bounds for the Ballmer Peak http://xkcd.com/323/ during their late night programming sessions; Katie and Peter will be establishing the Long Tail. He’s also great friends with Peter Gehres, but we won’t hold that against him. :-) Please join me in welcoming Matt to the Wikimedia Foundation. Take care, Terry terry chay 최태리 Director of Features Engineering Wikimedia Foundation “Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment.” p: +1 (415) 839-6885 x6832 m: +1 (408) 480-8902 e: tc...@wikimedia.org i: http://terrychay.com/ w: http://meta.wikimedia.org/wiki/User:Tychay aim: terrychay ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] StripState and ampersands?
I have a parser tag extension that calls $parser-insertStripItem() to add some
text to StripState:
function myCallback($input, $argv, $parser) {
return $parser-insertStripState(this is a test);
}
When the text renders on the wiki page, however, all ampersands have been
converted to amp;:
this is a amp; test
How can I prevent this conversion so ampersands (and presumably other special
characters) are preserved?
Thanks,
DanB
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] Announcement: Matt Walker joins Wikimedia as Fundraising Engineer
WELCOME MATT! On Fri, Jun 29, 2012 at 10:45 AM, Terry Chay tc...@wikimedia.org wrote: Hello everyone, It’s with great pleasure that I’m announcing that Matt Walker has joined the Wikimedia Foundation as a Fundraising Engineer. Before joining us, Matt was a software engineer at Rockwell Collins Control Technologies developing “a DO-178B level A qualified Real-Time Operating System in C and PowerPC assembly.” (Ask him about it.) He got his dual B.S. in EE and CS from the University of Tulsa with a minor in Mathematics. On the side, Matt enjoys tech theatre, glass blowing, SCUBA diving, hiking, and bicycling so I’m not sure how he’ll fit in with his move to the Bay Area. During the reference check, the department chair of Electrical Engineering at his uni regaled me with stories about a time lapse video project he self-started and having to sign a permission slip for a high school prom. His first official day will be on July 9th assuming he survives his cross-country trip through Wyoming and the Dakotas. (I’ve seen the trailers for Longmire http://en.wikipedia.org/wiki/Longmire_(TV_series) so it’s not a given — Wyoming sounds like a very dangerous place.) He will be working with the FR-Tech team trying to establish the lower bounds for the Ballmer Peak http://xkcd.com/323/ during their late night programming sessions; Katie and Peter will be establishing the Long Tail. He’s also great friends with Peter Gehres, but we won’t hold that against him. :-) Please join me in welcoming Matt to the Wikimedia Foundation. Take care, Terry terry chay 최태리 Director of Features Engineering Wikimedia Foundation “Imagine a world in which every single human being can freely share in the sum of all knowledge.* That's our commitment.*” p: +1 (415) 839-6885 x6832 m: +1 (408) 480-8902 e: tc...@wikimedia.org i: http://terrychay.com/ w: http://meta.wikimedia.org/wiki/User:Tychay aim: terrychay ___ Wmfall mailing list wmf...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wmfall -- James Alexander Manager, Merchandise Wikimedia Foundation (415) 839-6885 x6716 @jamesofur ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] Announcement: Matt Walker joins Wikimedia as Fundraising Engineer
Ah hah! And the Tulsa cabal increases by one more! Another step on our (long term...very long term) goal toward world domination, scheduled for the year 2320. Unless we get distracted. Hey, what's that shiny thing over there?... Welcome, Matt! PB --- Philippe Beaudette Director, Community Advocacy Wikimedia Foundation, Inc Sent from my Verizon Wireless BlackBerry -Original Message- From: Matthew Roth mr...@wikimedia.org Sender: wmfall-boun...@lists.wikimedia.org Date: Fri, 29 Jun 2012 11:50:51 To: Terry Chaytc...@wikimedia.org Cc: Staff Allwmf...@lists.wikimedia.org; Wikimedia developerswikitech-l@lists.wikimedia.org; Matthew Walkermwal...@khaosdev.com Subject: Re: [Wmfall] Announcement: Matt Walker joins Wikimedia as Fundraising Engineer ___ Wmfall mailing list wmf...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wmfall ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] StripState and ampersands?
How can I prevent this conversion so ampersands (and presumably other special characters) are preserved? Followup up my own question: StripState is not relevant here. It's the fact that it's a parser tag extension. Simply returning in the callback will produce amp;. Is there a way to suppress this conversion when returning from a parser tag extension? DanB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Ampersands and markerType=nowiki? (was RE: StripState and ampersands?)
In a parser tag callback, if I change this:
function myCallback($input, $argv, $parser) {
return '';
}
to this:
function myCallback($input, $argv, $parser) {
return array('', 'markerType' = 'nowiki');
}
shouldn't the second one cause a plain ampersand to be rendered, rather than
amp; ?
Reference:
http://www.mediawiki.org/wiki/Manual:Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.3F.
This is MediaWiki 1.18.1.
Thanks,
DanB
_
From: Daniel Barrett
Sent: Friday, June 29, 2012 3:42 PM
To: 'Wikimedia developers'
Subject: RE: StripState and ampersands?
How can I prevent this conversion so ampersands (and presumably other special
characters) are preserved?
Followup up my own question: StripState is not relevant here. It's the fact
that it's a parser tag extension. Simply returning in the callback will
produce amp;. Is there a way to suppress this conversion when returning
from a parser tag extension?
DanB
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Today's git master
$ git reset --hard HEAD is now at de13c31 Actually we have many contributors $ Chad, you made my day:) //Saper ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Barkeep code review tool
As seen on IRC: https://github.com/ooyala/barkeep/wiki/Comparing-Barkeep-to-other-code-review-tools //Saper ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] StripState and ampersands?
On 29/06/12 21:42, Daniel Barrett wrote: How can I prevent this conversion so ampersands (and presumably other special characters) are preserved? Followup up my own question: StripState is not relevant here. It's the fact that it's a parser tag extension. Simply returning in the callback will produce amp;. Is there a way to suppress this conversion when returning from a parser tag extension? DanB Why do you want a plain ? Seems like you want invalid html... ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Today's git master
On 29/06/12 22:41, Marcin Cieslak wrote: $ git reset --hard HEAD is now at de13c31 Actually we have many contributors $ Chad, you made my day:) //Saper Great commit! https://gerrit.wikimedia.org/r/13449 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New branch testing in operations/mediawiki-config
Le 29/06/12 18:36, Petr Bena wrote: But that's a lot of hand work, if we really do this, we won't use gerrit at all, we just copy paste code from diffs by hand and insert it to some extra files. I would rather volunteer to sync branches rather than this creep work. What hand work are you referring to? copy/paste in git world is something like: # Copy: git fetch repo ref # Paste: git merge FETCH_HEAD Anyway, anyone can clone the repository and do their stuff on their own. That is defacto a branch (your master is not the WMF master, it is a copy). A local commit can be distributed to over people via Gerrit. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Technical hurdles for enabling $wgHtml5 on Wikimedia sites?
Rob Lanphier wrote: Assuming we can either get these fixed, or agree they aren't blockers, I say we set a date and go. Should we plan on sometime in July (say a week or two after Wikimania)? Your e-mail was unclear to me. It's difficult to tell whether you just looked at the blockers of bug 27478 or if you read (all of) the bug's comments (and the related previous mailing list discussions about this). Are you following the deployment plan outlined by Roan here: https://bugzilla.wikimedia.org/show_bug.cgi?id=27478#c18? (It was a follow-up to Aryeh's post here: http://lists.wikimedia.org/pipermail/wikitech-l/2011-June/053775.html. As I understand it, the enable HTML5 on Wikimedia wikis goal has become a bit murky. There's $wgHtml5, but that's distinct from setting the doctype (which is what I think most people consider to be the most relevant part). It's unclear how many features (or more pointedly how many lines of additional code) are dependent on this configuration variable, which was part of the reason Aryeh laid out the deployment plan he did. It's also unclear whether every issue reported in the comments of bug 27478 were filed as separate bugs. In particular, I'm unsure if Cite was ever properly fixed (or if Aryeh's mentioned alternate, stop-gap solution was implemented). As I recall, the Cite breakage was breaking links in articles. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] New, lower traffic, announcements only email list for Wikimedia developers
Greetings, Following discussions with Wikimedia developers more on the fringe and not as engaged in frequent IRC or mailing list conversations, the request for an announcements only mailing list came up. I wanted to let folks know that this list has been created and is ready for membership: https://lists.wikimedia.org/mailman/listinfo/wikitech-announce - wikitech-annou...@lists.wikimedia.org There will also be a signup list for this and other lists at Wikimania Hackathon. Unlike this list, which allows for discussion, or the MediaWiki-announce list, which focuses exclusively on MediaWiki release announcements, wikitech-announce will be used for occasional announcements on both MediaWiki and broader Wikimedia developer related news items. This includes an announcement when monthly tech or engineering reports are posted, important news updates on git or developer related tools, and information on upcoming sprints, events or other major developer collaborations. Having presented this idea a few times, there are some common questions I will get out of the way now. Why not just send these out on MediaWiki-announce? There was quick reaction from several of these less-engaged developers that some really did want JUST MediaWiki release info sent out on that list. In other words, the audience of that list did not like the idea. Will this duplicate emails sent to wikitech-l? Probably, but it is not designed for folks already utilizing wikitech-l - it is designed for folks who would like less email traffic and want announcements - not conversations. Is this really going to save folks that many emails? In June, the wikitech-l list had 639 individual messages (so far). It is unlikely that this list would exceed 12 a month. For reference, MediaWiki-announce has sent out 3 messages this month and mediawiki-l had 121 messages. This list presents a middle ground between the two extremes. Do we not already have enough lists? Yes, but as our developer community grows, so too must our means of communicating. Many individuals, myself included, have been intentionally trying to engage developers generally less present, but just as important to our community. Such as corporate developers with an interest in sharing extensions who can benefit from announcements about git. Similarly, some students would prefer to get basic info that helps them stay on top of the latest developments. Generally, if you find yourself having a concern about this list, it is probably not the list for you to join. However, if you find yourself excited at the idea of less development chatter while remaining informed, this might just be the list for you. Thank you to Sumana and TheHelpfulOne for supporting this effort and to Daniel Renfro for proposing this idea and getting the discussion started. I have volunteered to moderate the list at its start, but will be interested in recruiting others that are willing to help. Anyone with an announcement can submit one, and a moderator will approve messages which fit within the list's scope. Finally, like any new tool, I anticipate its usage will evolve over time - so please do engage in discussion on any ideas you may have for its future. Thank you! -greg aka varnent ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
