[Wikitech-l] Make port 22 on gerrit.wikimedia.org default for git (same as what 29418 is now)
gerrit.wikimedia.org is a default git gateway for all of wikimedia projects, but it still has a number of issues compared to other (IMHO better) providers, like GitHub. One of major issues I am now having is, that git needs to be accessed using non-standard port because regular ssh access is still being served on port 22. This is a problem on restricted networks where random ports are prohibited and blocked for various reasons, while standard ports like 21, 22, 80 etc are open. I propose to move the current ssh port (22) to some non-standard port, as staff which needs to use it is far smaller than developer community that needs to access git (the server itself is for git only) and open port 22 as a gerrit (git) port. The current port 29418 can be used as well, so that nobody needs to update their repo's which were already cloned. This is technically possible and I think it would make usage of gerrit much less of a pain in the . Thanks for your considerations :P ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] planned move to phabricator
Hi Svetlana, Note that http://fab.wmflabs.org 's homepage and left column will look different (simpler) in Wikimedia Phabricator on Day 1. Phabricator upstream has added many improvements in this front in the past months. There is a preliminary discussion at http://fab.wmflabs.org/T12 We also discussed the names of tasks and decided to leave them as it is -- see http://fab.wmflabs.org/T119 In Phabricator projects are tags, tags are projects. There is no tree hierarchy, and there are no subprojects or (these might come in a near future, though). On Tuesday, August 26, 2014, svetlana svetl...@fastmail.com.au javascript:_e(%7B%7D,'cvml','svetl...@fastmail.com.au'); wrote: I've attempted to create a new bug, and use comments. Apparently I can't reply to comments (quoting the previous folks).? Yes, you can. Check the dropdown link at the right of the comment you want to quote. I just documented more answers to your questions at https://www.mediawiki.org/wiki/Phabricator/Help Thank you for these questions. They are useful to improve our user documentation before Day 1. If you (plural) have more questions, they are welcome at the very empty and very ready https://www.mediawiki.org/wiki/Talk:Phabricator/Help -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Make port 22 on gerrit.wikimedia.org default for git (same as what 29418 is now)
On Tue, 2014-08-26 at 10:34 +0200, Petr Bena wrote: One of major issues I am now having is, that git needs to be accessed using non-standard port because regular ssh access is still being served on port 22. This is a problem on restricted networks where random ports are prohibited and blocked for various reasons, while standard ports like 21, 22, 80 etc are open. Related ticket: https://bugzilla.wikimedia.org/show_bug.cgi?id=35611 andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Wikimedia engineering report, July 2014
Hi, The report covering Wikimedia engineering activities in July 2014 is now available. Wiki version: https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/2014/July Blog version: https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/ We're also proposing a shorter version of this report focusing on priority goals for this quarter: https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/2014/July/summary Below is the HTML text of the report. As always, feedback is appreciated on the usefulness of the report and its summary, and on how to improve them. -- Major news in July include: - a recap of how the Operations team collaborated with the RIPE NCC https://blog.wikimedia.org/2014/07/09/how-ripe-atlas-helped-wikipedia-users/ to measure the delivery of Wikimedia sites to users in Asia and elsewhere; - an analysis of the impact of the San Francisco data center https://blog.wikimedia.org/2014/07/11/making-wikimedia-sites-faster/ on the speed of Wikimedia sites; - the launch of the new native Wikipedia app for iOS https://blog.wikimedia.org/2014/07/31/official-wikipedia-app-available-on-ios-and-android/ ; - a first look at the content translation tool https://blog.wikimedia.org/2014/07/16/first-look-at-the-content-translation-tool/ . *Note: We’re also providing a shorter and translatable version of this report https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/2014/July/summary.* Engineering metrics in July: - 164 unique committers contributed patchsets of code to MediaWiki. - The total number ofunresolved commits https://gerrit.wikimedia.org/r/#q,status:open+project:%255Emediawiki.*,n,z went from around 1575 to about 1642. - About 31 shell requests https://www.mediawiki.org/wiki/Shell_requestswere processed. Contents - Personnel https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Personnel - Work with us https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Work_with_us - Announcements https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Announcements - Technical Operations https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Technical_Operations - Features Engineering https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Features_Engineering - Editor retention: Editing tools https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/_Editing_tools - Services https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Services - Core Features https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Core_Features - Growth https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Growth - Mobile https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Mobile - Language Engineering https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Language_Engineering - Platform Engineering https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Platform_Engineering - MediaWiki Core https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#MediaWiki_Core - Release Engineering https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Release_Engineering - Multimedia https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Multimedia - Engineering Community Team https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Engineering_Community_Team - Analytics https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Analytics - Kiwix https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Kiwix - 10 Wikidata https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Wikidata - 11 Future https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Future PersonnelWork with us https://wikimediafoundation.org/wiki/Work_with_us Are you looking to work for Wikimedia? We have a lot of hiring coming up, and we really love talking to active community members about these roles. - VP of Engineering http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qSa9VfwQcs=9UL9Vfwtpage=Job%20Descriptionj=ods8Xfwu - Software Engineer – Front-end (VisualEditor) http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qSa9VfwQcs=9UL9Vfwtpage=Job%20Descriptionj=o8jyYfwH - Software Engineer – Services http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qSa9VfwQcs=9UL9Vfwtpage=Job%20Descriptionj=oAhYYfwx - Software Engineer – Front-end http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qSa9VfwQcs=9UL9Vfwtpage=Job%20Descriptionj=oxgWYfwr - Software Engineer – Maps Geo
Re: [Wikitech-l] mediawiki now being tested with vendor repo
Le 25/08/2014 14:55, Antoine Musso a écrit : Will have to adjust the qunit job to use mediawiki/vendor as well. The mediawiki-core-qunit job is now cloning mediawiki/vendor as well :] -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disabling JS support in additional browsers
One thing that comes to mind is that CentralNotice is dependent on JS. Blacklisting browsers means they won't see CentralNotice banners at all. This isn't really a big concern for Fundraising: it's a small percentage of views, and not having to support these browsers in our increasingly sophisticated banners is probably a blessing. However I wonder about other uses of CentralNotice e.g. letting people know about the recent Privacy Policy and Terms of Use changes. Where we not only want to reach as many users as possible, but may also have legal obligations to. I'm not really sure how big an issue this is, or how to solve it. On 6 August 2014 19:52, Erik Moeller e...@wikimedia.org wrote: Following up on disabling JavaScript support for IE6 [1], here is some additional research on other browsers. I'd appreciate if people with experience testing/developing for/with these browsers would jump in with additional observations. I think we should wait with adding other browsers to the blacklist until the IE6 change has been rolled out, which may expose unanticipated consequences (it already exposed that Common.js causes errors in blacklisted browsers, which should be fixed once [2] is reviewed and merged). As a reminder, the current blacklist is in resources/src/startup.js. As a quick test, I tested basic browsing/editing operation on English Wikipedia with various browsers. Negative results don't necessarily indicate that we should disable JS support for these browsers, but they do indicate the quality of testing that currently occurs for those browsers. Based on a combination of test results, unpatched vulnerabilities and usage share, an initial recommendation for each browser follows. Note that due to the heavy customization through gadgets/site scripts, there are often site-specific issues which may not be uncovered through naive testing. == Microsoft Internet Explorer 7.x == Last release in series: April 2009 - Browsing: Most pages work fine (some styling issues), but pages with audio files cause JavaScript errors (problem in TMH). - Editing: Throws JS error immediately (problem in RefToolbar) Both of these errors don't occur in IE8. Security vulnerabilities: Secunia reports 15 out of 87 vulnerabilities as unpatched, with the most serious one being rated as moderately critical (which is the same as IE6, while the most serious IE8 vulnerability is rated less critical). Usage: 1% Recommendation: Add to blacklist == Opera 8.x == Last release in series: September 2005 Browsing/editing: Works fine, but all JS fails due to a script execution error (which at least doesn't cause a pop-up). Security: Secunia reports 0 unpatched vulnerabilities (out of 26). Usage: 0.25% Recommendation: Add to blacklist == Opera 10.x-12.x == Last release in series: April 2014 Browsing/editing: Works fine, including advanced features like MediaViewer (except for 10.x) Security: No unpatched vulnerabilities in 12.x series according to Secunia, 2 unpatched vulnerabilities in 11.x (less critical) and 1 unpatched vulnerability in 10.x (moderately critical) Usage: 1% Recommendation: Maintain basic JS support, but monitor situation re: 10.x and add that series to blacklist if maintenance cost too high == Firefox 3.6.* == Last release in series: March 2012 Browsing/editing: Works fine (MediaViewer disables itself) Security: 0 unpatched vulnerabilities according to Secunia Recommendation: Maintain basic JS support == Firefox 3.5.* == Last release in series: April 2011 Browsing/editing: Works fine (MediaViewer disables itself) Security: 0 unpatched vulnerabilities according to Secunia Recommendation: Maintain basic JS support == Safari 4.x == Last release in series: November 2010 Browsing/editing: Works fine Security: 1 unpatched highly critical vulnerability according to Secunia (exposure of sensitive information) Recommendation: Maintain basic JS support, but monitor == Safari 3.x == Last release in series: May 2009 Browsing/editing: Completely messed up, looks like CSS doesn't get loaded at all Security: 2 unpatched vulnerabilities, highly critical Usage share: Usage reports for Safari in [3] are broken, all Safari versions are reported as 0.0. However, [4] suggests that Safari 3 usage is negligible/non-existent. Recommendation: Styling issue may be worth investigating in case it affects other browsers and/or is JS-caused. Otherwise probably can be safely ignored. [1] http://lists.wikimedia.org/pipermail/wikitech-l/2014-August/077952.html [2] https://gerrit.wikimedia.org/r/#/c/152122/ [3] http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm [4] http://stackoverflow.com/questions/12655363/what-is-the-most-old-safari-version-which-is-used-so-far-by-users -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ Wikitech-l
Re: [Wikitech-l] build.wikimedia.org
On Mon, Aug 25, 2014 at 01:54:28PM -0700, Legoktm wrote: This is now at [[dev.wikimedia.org]]? That sounds like a much better name than build, which I thought was going to be some CI automated builds server from your email title :) But also sounds like it's the absolute end of the line for development work, cf. mediawiki.org. I'll say from personal experience that when I find a website that links to a developers resource, and that resource is all about APIs and data, I ragequit the browser tab because the software is clearly not modifiable, they just want people to play with the toys they've allowed. This is pretty well illustrated by the list of external examples. Is there any discussion of the name of the portal? -- Mark Holmquist Software Engineer, Multimedia Wikimedia Foundation mtrac...@member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] build.wikimedia.org
On 26 August 2014 08:57, Mark Holmquist mtrac...@member.fsf.org wrote: On Mon, Aug 25, 2014 at 01:54:28PM -0700, Legoktm wrote: This is now at [[dev.wikimedia.org]]? That sounds like a much better name than build, which I thought was going to be some CI automated builds server from your email title :) But also sounds like it's the absolute end of the line for development work, cf. mediawiki.org. I'll say from personal experience that when I find a website that links to a developers resource, and that resource is all about APIs and data, I ragequit the browser tab because the software is clearly not modifiable, they just want people to play with the toys they've allowed. This is pretty well illustrated by the list of external examples. Is there any discussion of the name of the portal? Hey Mark, You might have missed the links from earlier in the thread: On 25 August 2014 18:10, MZMcBride z...@mzmcbride.com wrote: Legoktm wrote: This is now at [[dev.wikimedia.org]]? That sounds like a much better name than build, which I thought was going to be some CI automated builds server from your email title :) Seems so; related links: * http://fab.wmflabs.org/T490 * http://fab.wmflabs.org/T492 * http://fab.wmflabs.org/T487 J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] mediawiki now being tested with vendor repo
Great news! Hope this will come to extension/ too soon. We have got composer installed dependencies both in SwiftMailer[1] and BounceHandler[2]. We even had to make a no-dependency-workaround ready in Bouncehandler to make sure that it works without $composer update. Still remember that long threads we had on swiftmailer earlier :) It would be great, if we can install default skins too in this fashion. I just found the new installation mode of copying manually libraries to skins/ a bit difficult, thats why. [1]https://www.mediawiki.org/wiki/Extension:SwiftMailer [2] https://www.mediawiki.org/wiki/Extension:BounceHandler Thanks, Tony Thomas http://tttwrites.wordpress.com/ FOSS@Amrita http://foss.amrita.ac.in *where there is a wifi, there is a way* On Tue, Aug 26, 2014 at 7:19 PM, Antoine Musso hashar+...@free.fr wrote: Le 25/08/2014 14:55, Antoine Musso a écrit : Will have to adjust the qunit job to use mediawiki/vendor as well. The mediawiki-core-qunit job is now cloning mediawiki/vendor as well :] -- 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] Wikimedia engineering report, July 2014
Not sure what the problem is but the report on mw.o is borked. See screenshot: https://www.mediawiki.org/wiki/File:Aug2014-monthlyreport-busted.png On Tue, Aug 26, 2014 at 3:45 AM, Guillaume Paumier gpaum...@wikimedia.org wrote: Hi, The report covering Wikimedia engineering activities in July 2014 is now available. Wiki version: https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/2014/July Blog version: https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/ We're also proposing a shorter version of this report focusing on priority goals for this quarter: https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/2014/July/summary Below is the HTML text of the report. As always, feedback is appreciated on the usefulness of the report and its summary, and on how to improve them. -- Major news in July include: - a recap of how the Operations team collaborated with the RIPE NCC https://blog.wikimedia.org/2014/07/09/how-ripe-atlas-helped-wikipedia-users/ to measure the delivery of Wikimedia sites to users in Asia and elsewhere; - an analysis of the impact of the San Francisco data center https://blog.wikimedia.org/2014/07/11/making-wikimedia-sites-faster/ on the speed of Wikimedia sites; - the launch of the new native Wikipedia app for iOS https://blog.wikimedia.org/2014/07/31/official-wikipedia-app-available-on-ios-and-android/ ; - a first look at the content translation tool https://blog.wikimedia.org/2014/07/16/first-look-at-the-content-translation-tool/ . *Note: We’re also providing a shorter and translatable version of this report https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/2014/July/summary .* Engineering metrics in July: - 164 unique committers contributed patchsets of code to MediaWiki. - The total number ofunresolved commits https://gerrit.wikimedia.org/r/#q,status:open+project:%255Emediawiki.*,n,z went from around 1575 to about 1642. - About 31 shell requests https://www.mediawiki.org/wiki/Shell_requestswere processed. Contents - Personnel https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Personnel - Work with us https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Work_with_us - Announcements https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Announcements - Technical Operations https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Technical_Operations - Features Engineering https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Features_Engineering - Editor retention: Editing tools https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/_Editing_tools - Services https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Services - Core Features https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Core_Features - Growth https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Growth - Mobile https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Mobile - Language Engineering https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Language_Engineering - Platform Engineering https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Platform_Engineering - MediaWiki Core https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#MediaWiki_Core - Release Engineering https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Release_Engineering - Multimedia https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Multimedia - Engineering Community Team https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Engineering_Community_Team - Analytics https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Analytics - Kiwix https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Kiwix - 10 Wikidata https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Wikidata - 11 Future https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/#Future PersonnelWork with us https://wikimediafoundation.org/wiki/Work_with_us Are you looking to work for Wikimedia? We have a lot of hiring coming up, and we really love talking to active community members about these roles. - VP of Engineering http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qSa9VfwQcs=9UL9Vfwtpage=Job%20Descriptionj=ods8Xfwu - Software Engineer – Front-end (VisualEditor)
Re: [Wikitech-l] Wikimedia engineering report, July 2014
On Tue, Aug 26, 2014 at 4:55 PM, Arthur Richards aricha...@wikimedia.org wrote: Not sure what the problem is but the report on mw.o is borked. See screenshot: https://www.mediawiki.org/wiki/File:Aug2014-monthlyreport-busted.png Transient error on fetching CSS asset from bits? Works for me. (but i've seen something like that before on other pages. I think) -Jeremy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia engineering report, July 2014
On Tue, Aug 26, 2014 at 10:04 AM, Jeremy Baron jer...@tuxmachine.com wrote: On Tue, Aug 26, 2014 at 4:55 PM, Arthur Richards aricha...@wikimedia.org wrote: Not sure what the problem is but the report on mw.o is borked. See screenshot: https://www.mediawiki.org/wiki/File:Aug2014-monthlyreport-busted.png Transient error on fetching CSS asset from bits? Works for me. (but i've seen something like that before on other pages. I think) I'm definitely getting the same as Arthur. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia engineering report, July 2014
Same here, but only in Chrome, not in FF and not in IE, versions: Chrome: 36.0.1985.143 m FF: 31.0 IE: 11.09600.17239 Freundliche Grüße / Kind regards Florian -Ursprüngliche Nachricht- Von: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Chad Gesendet: Dienstag, 26. August 2014 19:07 An: Wikimedia developers Betreff: Re: [Wikitech-l] Wikimedia engineering report, July 2014 On Tue, Aug 26, 2014 at 10:04 AM, Jeremy Baron jer...@tuxmachine.com wrote: On Tue, Aug 26, 2014 at 4:55 PM, Arthur Richards aricha...@wikimedia.org wrote: Not sure what the problem is but the report on mw.o is borked. See screenshot: https://www.mediawiki.org/wiki/File:Aug2014-monthlyreport-busted.png Transient error on fetching CSS asset from bits? Works for me. (but i've seen something like that before on other pages. I think) I'm definitely getting the same as Arthur. -Chad ___ 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] Wikimedia engineering report, July 2014
Me too. Dan On Tuesday, 26 August 2014, Chad innocentkil...@gmail.com wrote: On Tue, Aug 26, 2014 at 10:04 AM, Jeremy Baron jer...@tuxmachine.com javascript:; wrote: On Tue, Aug 26, 2014 at 4:55 PM, Arthur Richards aricha...@wikimedia.org javascript:; wrote: Not sure what the problem is but the report on mw.o is borked. See screenshot: https://www.mediawiki.org/wiki/File:Aug2014-monthlyreport-busted.png Transient error on fetching CSS asset from bits? Works for me. (but i've seen something like that before on other pages. I think) I'm definitely getting the same as Arthur. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia engineering report, July 2014
On Tue, Aug 26, 2014 at 6:55 PM, Arthur Richards aricha...@wikimedia.org wrote: Not sure what the problem is but the report on mw.o is borked. See screenshot: This should now be fixed; Thank you for the bug report, and my apologies for the inconvenience :) -- Guillaume Paumier ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia engineering report, July 2014
Looks good to me. Thanks Guillaume. :-) Dan On 26 August 2014 11:05, Guillaume Paumier gpaum...@wikimedia.org wrote: On Tue, Aug 26, 2014 at 6:55 PM, Arthur Richards aricha...@wikimedia.org wrote: Not sure what the problem is but the report on mw.o is borked. See screenshot: This should now be fixed; Thank you for the bug report, and my apologies for the inconvenience :) -- Guillaume Paumier ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Call for reviewers: structured logging
Thanks to a lot of hard work by Antoine [0], Zuul and Jenkins are now testing things using the mediawiki/vendor repository. This unblocks my patches that implement PSR-3 logging for the structured logging RFC [1]: * Add a PSR-3 based logging interface - https://gerrit.wikimedia.org/r/#/c/119940/ * Use MWLogger logging for legacy logging methods - https://gerrit.wikimedia.org/r/#/c/119941/ * Use MWLogger logging for wfLogProfilingData - https://gerrit.wikimedia.org/r/#/c/119942/ * Add logging context to database logs - https://gerrit.wikimedia.org/r/#/c/141599/ I'd love to see these reviewed and merged. :) [0]: http://www.gossamer-threads.com/lists/wiki/wikitech/498938 [1]: https://www.mediawiki.org/wiki/Requests_for_comment/Structured_logging -- Bryan Davis Wikimedia Foundationbd...@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software EngineerBoise, ID USA irc: bd808v:415.839.6885 x6855 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disabling JS support in additional browsers
On 26 Aug 2014, at 16:34, Peter Coombe pcoo...@wikimedia.org wrote: One thing that comes to mind is that CentralNotice is dependent on JS. Blacklisting browsers means they won't see CentralNotice banners at all. This isn't really a big concern for Fundraising: it's a small percentage of views, and not having to support these browsers in our increasingly sophisticated banners is probably a blessing. However I wonder about other uses of CentralNotice e.g. letting people know about the recent Privacy Policy and Terms of Use changes. Where we not only want to reach as many users as possible, but may also have legal obligations to. I'm not really sure how big an issue this is, or how to solve it. I don't have a legal-relevant answer, but for what it's worth, this isn't new. We've always blacklisted older browsers. This is just our annual updating of what that blacklist is. This in order to prevent maintenance costs from increasing exponentially. Because, new browsers are coming out continuously, keeping support for old browsers means we're supporting more, not the same, as last year. And it allows us to start using newer technologies and stop having to account for older browser bugs in new features we develop. This includes usage of existing features, such as CentralNotice banners indeed. Each banner that's made is paying a small human-resources price ensuring it works in all supported browsers. As for the legal part, I'm not a lawyer, but in my limited knowledge two things come to mind: * Is announcing policy changes legally required? Or is it a recommended courtesy? Many policies contain stuff like We reserve the right to change this at any time.. Does ours? And either way, visitors didn't explicitly agree to the version that applied to them either, so one would think that whatever legal mechanism allows that, also means we can't be required to inform them about changes. * These kind of announcements probably shouldn't require javascript if that's the case. Remember, even if we'd support every single browser ever, if they don't have javascript or if they disabled javascript, the banners won't appear either. Would we be required to display the banner in a way that doesn't require javascript? Quite a few extremist (sorry) out there have javascript disabled in their browser. We use javascript at all due to technical restrictions related to site performance (changing the banners without purging every single article on every wiki from cache, js seems the only way to project changed content separately). -- Krinkle Interesting read: http://www.theverge.com/2014/8/19/6044679/the-six-lawsuits-that-shaped-the-internet ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Call for reviewers: structured logging
Le 26/08/2014 21:43, Bryan Davis a écrit : Thanks to a lot of hard work by Antoine [0], Zuul and Jenkins are now testing things using the mediawiki/vendor repository. This unblocks my patches that implement PSR-3 logging for the structured logging RFC [1]: * Add a PSR-3 based logging interface - https://gerrit.wikimedia.org/r/#/c/119940/ * Use MWLogger logging for legacy logging methods - https://gerrit.wikimedia.org/r/#/c/119941/ * Use MWLogger logging for wfLogProfilingData - https://gerrit.wikimedia.org/r/#/c/119942/ * Add logging context to database logs - https://gerrit.wikimedia.org/r/#/c/141599/ I'd love to see these reviewed and merged. :) [0]: http://www.gossamer-threads.com/lists/wiki/wikitech/498938 [1]: https://www.mediawiki.org/wiki/Requests_for_comment/Structured_logging And I forgot to tell Bryan that jobs running for extensions are not yet migrated to clone vendor as well :-\ But definitely review those nice patches and give them a try. That will tremendously improve the MediaWiki logging infrastructure and open the path to better diagnosis and monitoring of the live sites. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] The future of skins
Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and talked about the future of skins. Hopefully this mail summarises what we talked about and what we agreed on. Feel free to add anything, or ask any questions in the likely event that I've misinterpreted something we talked about or this is unclear :) Specifically we talked about how we are unhappy with how difficult it currently is for developers to create a skin. The skin class involves too many functions and does more than a skin should do e.g. manage classes on the body, worry about script tags and style tags. Trevor is going to create a base set of widgets, for example a list generator to generate things like a list of links to user tools. The widgets will be agnostic to how they are rendered - some may use templates, some may not. We identified the new skin system will have two long term goals: 1) We would like to get to the point where a new skin can be built by simply copying and pasting a master template and writing a new css file. 2) Should be possible for us in future to re-render an entire page via JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing) As next steps we agreed to do the following: 1) Trevor is going to build a watch star widget on client and server. We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September. 2) We need a templating system in core. Trevor is going to do some research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements. [1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Pre-release announcement for MediaWiki releases 1.22.10 and 1.23.3
Hello everyone, this is a notice that on 27th August between 20:00-22:00 UTC we will release maintenance updates for current and legacy branches of the MediaWiki software. Downloads and patches will be available at that time. Best, Markus Wiki Release Team ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Pre-release announcement for MediaWiki releases 1.22.10 and 1.23.3
So 1.19 is officially finished? On 27 August 2014 01:02, Markus Glaser gla...@hallowelt.biz wrote: Hello everyone, this is a notice that on 27th August between 20:00-22:00 UTC we will release maintenance updates for current and legacy branches of the MediaWiki software. Downloads and patches will be available at that time. Best, Markus Wiki Release Team ___ 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] The future of skins
Thanks for summarizing the meeting Jon. So, let's get Twig/Swig into core then, eh? :) - Trevor On Tue, Aug 26, 2014 at 3:53 PM, Jon Robson jrob...@wikimedia.org wrote: Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and talked about the future of skins. Hopefully this mail summarises what we talked about and what we agreed on. Feel free to add anything, or ask any questions in the likely event that I've misinterpreted something we talked about or this is unclear :) Specifically we talked about how we are unhappy with how difficult it currently is for developers to create a skin. The skin class involves too many functions and does more than a skin should do e.g. manage classes on the body, worry about script tags and style tags. Trevor is going to create a base set of widgets, for example a list generator to generate things like a list of links to user tools. The widgets will be agnostic to how they are rendered - some may use templates, some may not. We identified the new skin system will have two long term goals: 1) We would like to get to the point where a new skin can be built by simply copying and pasting a master template and writing a new css file. 2) Should be possible for us in future to re-render an entire page via JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing) As next steps we agreed to do the following: 1) Trevor is going to build a watch star widget on client and server. We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September. 2) We need a templating system in core. Trevor is going to do some research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements. [1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library ___ 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] Pre-release announcement for MediaWiki releases 1.22.10 and 1.23.3
On 8/26/14, 5:10 PM, David Gerard wrote: So 1.19 is officially finished? https://www.mediawiki.org/wiki/MediaWiki_1.19 says it will be supported until May 2015. I think the reason there is no maintenance release for it is because nothing has been backported since the last security release: https://gerrit.wikimedia.org/r/#/q/project:mediawiki/core+branch:REL1_19+status:merged,n,z. -- Legoktm On 27 August 2014 01:02, Markus Glaser gla...@hallowelt.biz wrote: Hello everyone, this is a notice that on 27th August between 20:00-22:00 UTC we will release maintenance updates for current and legacy branches of the MediaWiki software. Downloads and patches will be available at that time. Best, Markus Wiki Release Team ___ 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The future of skins
On Tue, Aug 26, 2014 at 6:21 PM, Trevor Parscal tpars...@wikimedia.org wrote: Thanks for summarizing the meeting Jon. So, let's get Twig/Swig into core then, eh? :) It would be trivially simple to add twig (or any other Composer managed templating library) to mediawiki/vendor.git following the process outlined in the recently accepted Composer managed libraries RFC [0]. [0]: https://www.mediawiki.org/wiki/Requests_for_comment/Composer_managed_libraries_for_use_on_WMF_cluster -- Bryan Davis Wikimedia Foundationbd...@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software EngineerBoise, ID USA irc: bd808v:415.839.6885 x6855 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The future of skins
On Tue, Aug 26, 2014 at 8:21 PM, Trevor Parscal tpars...@wikimedia.org wrote: Thanks for summarizing the meeting Jon. So, let's get Twig/Swig into core then, eh? :) Please yes. Twig is really powerful, pretty fast, and is supported by a major company. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
