Re: [Wikitech-l] Separation of Concerns
On 06/06/13 05:23, Chris Steipp wrote: On Tue, Jun 4, 2013 at 9:00 PM, Tyler Romeo tylerro...@gmail.com wrote: I'm sure you did, but it's kind of useless if nobody provides an explanation. Do you really expect me to just accept that some WMF engineers somewhere decided it was best? I should have logged and posted our irc chats around this, but I didn't think of that at the time. That's my fault. I'll try and reconstruct the discussions we had on wiki. I posted the IRC logs of all the CentralAuth/OAuth weekly meetings on mediawiki.org, except perhaps for a two-week gap around the Hackathon -- if there was an IRC meeting at that time, I wasn't in it. The links are here: https://www.mediawiki.org/wiki/Auth_systems/OAuth -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On 06/06/13 07:14, Daniel Friesen wrote: You'll need: * A list of rights to omit and just automatically grant (minoredit, etc...). * A map of rights naming what group they belong to. * A rule to remove read from the list when the wiki is public and a hook to let extensions do similar with their rights. * A map showing how to combine multiple rights into one key eg: `'editcreateall' = array( 'edit', 'createpage', 'createtalk' )` or perhaps instead a method and hook. * And some new i18n text for the rights and new keys (frankly it's good to re-do the i18n anyways, a grant page is best with more informative text like Edit existing content as me or under my name, etc... rather than blindly repeating the right's normal i18n like Edit pages (edit)) So that's basically a flat configuration array, a key-value configuration array, a few lines of code with a hook, a tiny bit more code or an array, and some new entries to MessagesEn.php. Brad, Chris and I discussed this on IRC today. I think we can do something along these lines, with about 1-2 weeks of additional work. I think it will lead to a nicer UI, which definitely should be a goal. The IRC log is here: https://www.mediawiki.org/wiki/Auth_systems/OAuth/IRC_log_2013-06-06 I'm recommending making these groups of rights be both a UI concept and a storage concept, very similar to the existing group feature, rather than storing right grants and somehow bidirectionally mapping them to group grants in the UI layer. That way, future code changes can split rights (e.g. upload - upload/reupload), and have all the OAuth grants be implicitly updated by changing the group map. Since we would go crazy trying to talk about both the OAuth feature and the existing user feature as being groups, Chris suggested using the term permission to refer to the fundamental unit of an OAuth grant. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Fri, Jun 7, 2013 at 2:58 AM, Tim Starling tstarl...@wikimedia.orgwrote: I'm recommending making these groups of rights be both a UI concept and a storage concept, very similar to the existing group feature, rather than storing right grants and somehow bidirectionally mapping them to group grants in the UI layer. That way, future code changes can split rights (e.g. upload - upload/reupload), and have all the OAuth grants be implicitly updated by changing the group map. Sounds good to me. Since we would go crazy trying to talk about both the OAuth feature and the existing user feature as being groups, Chris suggested using the term permission to refer to the fundamental unit of an OAuth grant. But then wouldn't it be confused with permissions? Why not just call it a grant? Though I guess that has it's own issues since OAuth has authorization grants... *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Separate bug report status when patch is in Gerrit?
On Fri, Jun 7, 2013 at 6:24 AM, Matthew Flaschen mflasc...@wikimedia.orgwrote: Also I'm not sure 'Verified' is completely unused... I don't generally use it, but I've seen the QA/browser testing team do so. That would probably be only me. :) I can live without verified. Željko ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ???!!! ResourceLoader loading extension CSS DYNAMICALLY?!!
Hi! Sorry for not answering via normal Reply, it's because I'm getting messages in digests. But I want to say thanks for clarification and for position=top advice - it's OK with position=top. Thanks :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Relaxing our TorBlock
https://twitter.com/ioerror/status/342922052841377793 Why not - would the patrol cost really be too high? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Relaxing our TorBlock
On 7 June 2013 16:43, Asher Feldman afeld...@wikimedia.org wrote: https://twitter.com/ioerror/status/342922052841377793 Why not - would the patrol cost really be too high? Are you asking that question as a patroller? If not, then you should probably ask on the wikis first. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Relaxing our TorBlock
On 06/07/2013 08:43 AM, Asher Feldman wrote: https://twitter.com/ioerror/status/342922052841377793 Why not - would the patrol cost really be too high? Discussion from December: http://www.gossamer-threads.com/lists/wiki/wikitech/323006 Can we help Tor users make legitimate edits? -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Relaxing our TorBlock
Ah, thanks Sumana! On Friday, June 7, 2013, Sumana Harihareswara wrote: On 06/07/2013 08:43 AM, Asher Feldman wrote: https://twitter.com/ioerror/status/342922052841377793 Why not - would the patrol cost really be too high? Discussion from December: http://www.gossamer-threads.com/lists/wiki/wikitech/323006 Can we help Tor users make legitimate edits? -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcome to Ken Snider, Wikimedia Operations
On 06/06/2013 09:17 AM, Erik Moeller wrote: Ken got involved in one of Cory’s pet projects, BoingBoing.net which some of you may have heard of ;-), and has been their sysadmin since 2003. I continue to marvel at the cool experience my colleagues bring to their work. OpenCOLA and Boing Boing! Welcome, Ken. And thank you CT for your dedication! -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Relaxing our TorBlock
On Fri, Jun 7, 2013 at 8:43 AM, Asher Feldman afeld...@wikimedia.org wrote: https://twitter.com/ioerror/status/342922052841377793 Why not - would the patrol cost really be too high? What I've heard is that the edits from tor were over 90% spam/vandalism, so the IPs get blocked pretty quickly. Torblock (the tool) lets us do it preemptively. Unfortunately, removing the blocks to test those assumptions could generate a lot more work for our already overworked vandalism fighters, so I would be hesitant to even test it. But if someone has a wiki, and wants to setup torblock with an abusefilter rule to tag edits from tor nodes, and measure the spam/ham ratios, I would be interested in the results. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Strange PHPUnit behaviour
Hola! I noticed something very strange in unit tests for /languages/Language.php (/tests/phpunit/languages/LanguageTest.php): Language::sprintfDate() is tested to conform with expected formatted date strings. In the test file method 'provideSprintfDateSamples' provides a test case for the format bit 'W' which means ISO 8601 week number, zero-padded. Language::sprintfDate() outputs the result for W as documented. However, one of the test cases for this format contains expected value 1 (instead of 01). As I said above, sprintfDate() adds a zero (printing 01), but when I run the tests, they just pass! What is wrong here? Wrong test case + issue in PHPUnit or what? -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Relaxing our TorBlock
On 06/07/2013 11:43 AM, Asher Feldman wrote: Why not - would the patrol cost really be too high? I can only speak for enwp, of course, but with my experience as a checkuser and arb there (and a couple years as an admin before that) I can say without a doubt that I would strenuously oppose relaxing TOR restrictions: I have never seen a TOR exit node used for legitimate purposes, ever, with the notable exception of a handful (less than 10) editors who had been carefully vetoed prior. In fact, even some of those supposedly legitimate editors have fallen to the lure of easy socking when given the opportunity. That said, however, there are geopolitical concerns that may well justify the cost for /some/ projects. I could see why zhwiki might well feel the balance tips the other way, for instance. -- Marc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Strange PHPUnit behaviour
On Fri, Jun 7, 2013 at 12:36 PM, Paul Selitskas p.selits...@gmail.com wrote: What is wrong here? Wrong test case + issue in PHPUnit or what? Fun with PHP comparison. With the == and != operators (which are what PHPUnit's assertEquals is probably using), PHP notices that 1 and 01 are both numeric strings so it decides to compare them as numbers. http://php.net/manual/en/language.operators.comparison.php -- Brad Jorsch Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Strange PHPUnit behaviour
What Brad said. In this case, I believe the assertSame function should be used instead, which emulates ===. On Jun 7, 2013 1:55 PM, Brad Jorsch bjor...@wikimedia.org wrote: On Fri, Jun 7, 2013 at 12:36 PM, Paul Selitskas p.selits...@gmail.com wrote: What is wrong here? Wrong test case + issue in PHPUnit or what? Fun with PHP comparison. With the == and != operators (which are what PHPUnit's assertEquals is probably using), PHP notices that 1 and 01 are both numeric strings so it decides to compare them as numbers. http://php.net/manual/en/language.operators.comparison.php -- Brad Jorsch Software Engineer Wikimedia Foundation ___ 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] Deployment highlights - week of June 10th
Hello and welcome to the latest installment of your friendly deployment highlights! The full calendar for next week is available at: https://wikitech.wikimedia.org/wiki/Deployments#Week_of_June_10th Here are the highlights: == Overall == * The week of June 10th is the first clean one-week cycle. Please let me know if you run into any problems, either as a developer or an editor. == Monday == * MediaWiki 1.22wmf6 will go out to all non-WP project sites (eg: Commons, Wikisource, et al). == Tuesday == * The phasing out of WebFonts and Narayam begins in preparation for the ULS deployment. For all of the detailed details, see: https://www.mediawiki.org/wiki/UniversalLanguageSelector/Deployment/Planning == Thursday == * MediaWiki ** 1.22wmf6 goes out to all 'pedias. ** 1.22wmf7 begins and goes out to test/test2/mediawiki.org ** Full roadmap: https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap#Schedule_for_the_deployments Let me know if you have any questions! Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Architecture Guidelines: Writing Testable Code
I generally agree with 2-8, and 10. I think points 2 and 10 are pretty subjective and must be applied very pragmatically. -- View this message in context: http://wikimedia.7.x6.nabble.com/Architecture-Guidelines-Writing-Testable-Code-tp5006129p5006712.html Sent from the Wikipedia Developers mailing list archive at Nabble.com. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Last weekend for proposal work! (was Re: Request for proposals: MediaWiki release management)
And, your Friday before it's due ping. This is your last weekend to work on it! quote name=Greg Grossmeier date=2013-05-21 time=10:54:01 -0700 Hello all, I'm excited to share that we just opened an RFP for the Release Management of MediaWiki! More information below. The announcement blog post: https://blog.wikimedia.org/2013/05/21/request-for-proposals-mediawiki-release-management/ The RFP (PDF): https://upload.wikimedia.org/wikipedia/commons/a/a1/RFP-MediaWikiReleaseManagement.pdf The central MediaWiki.org wiki page where proposals will be submitted and reviewed: https://www.mediawiki.org/wiki/Release_Management_RFP Let me and/or Rob Lanphier (ro...@wikimedia.org) know if you have any questions. Best, Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New git-review lets you configure 'origin' as the gerrit remote
This is great! Origin and gerrit remotes disagreeing could potentially cause havoc. saper and I went through some tutorials telling people to use `git clone -o gerrit` when starting development, but this is much cleaner. I added it to https://www.mediawiki.org/wiki/Gerrit/Tutorial#Prepare_to_work_with_gerrit For existing repos you wrote: You'll need to perform an additional step to migrate existing repositories. In each repository, run the following commands: git remote set-url origin $(git config --get remote.gerrit.url) git remote rm gerrit git review -s If you don't do this, your first git review in each project after adding git - review.conf will do the git review -s step for you. If you have local branches tracking a gerrit remote (because you followed the git advice/lore to always begin feature work with git checkout -b my_new_feature -t gerrit/master ) then they'll now be disconnected, and you'll have empty sections for them in the project's ~/.config. When you try to update your local master branch, git nicely tells you how to fix this: MyProjRepo% git pull --ff-only There is no tracking information for the current branch. Please specify which branch you want to merge with. See git-pull(1) for details git pull remote branch If you wish to set tracking information for this branch you can do so with: *git branch --set-upstream-to=origin/**branch** master* So do this for your local branches tracking the remote master on gerrit: MyProjRepo% git branch --set-upstream-to origin/master master MyProjRepo% git branch --set-upstream-to origin/master my_new_feature etc. -- =S Page ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
