[Wikitech-l] Testing FS Path Permissions in PHPUnit
Hi, I'm retaking the work I started a couple of weeks ago in the Amsterdam Hackathon about improving code coverage of the Upload code. At the moment my main question is how to test all the code paths dealing with files not written to the FS because of permissions, missing dirs, etc. Is there a recommended way to do this already in the PHPUnit tests? I have checked a couple of tests and haven't found anything similar but if you can point me to one test, or let me know what's the best way to try that, I can take it from there. Thanks in advance. David E. Narvaez ___ 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/04/2013 09:48 PM, Daniel Friesen wrote: > Next autoconfirmed. This one you might just filter out to. Does anyone > know of any situation you'd expect OAuth to let an app "Edit any page I > can edit, but not the semi-protected ones I could usually edit."? > > edit, createpage, and createtalk can actually be grouped and combined > into a single entry and group. Likewise deletedhistory and deletedtext > can be combined into one entry in a separate common group. > > Like so: > ((Grant this app permission to)) > ## Editing > * Edit existing content and create pages and talkpage as me. > ## Administrative > * View deleted history entries, text, and changes. This makes sense to me. Showing every right on the scope screen by default is too granular and confusing, but sensible clumps of existing rights should work. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Tue, Jun 4, 2013 at 9:50 PM, Brad Jorsch wrote: > No, it doesn't. You think we didn't discuss this already? 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"? If you go by module, then you have problems where you need to grant > specific rights for using modules like list=categorymembers and > prop=revisions, but you can't grant the ability to edit normal pages > without also granting the ability to edit your user CSS/JS, and (if > you're an admin) the MediaWiki namespace and so on. So at least you're aware of the issues with the module system. The situation with user rights isn't any better. Editing a page requires 'edit' and 'writeapi' (and also 'read' unless you're blindly > overwriting pages), and likely 'minoredit' and 'skipcaptcha' would > also be wanted, and maybe also 'createpage', 'createtalk', > 'autoreview', 'autopatrol', 'autoconfirmed', and 'bot'. And at the > same time, you can't avoid granting the permission to write to your > user CSS/JS. There's a difference between the permissions interface in the actual API and the permissions interface in the UI. A bot may ask for "read|writeapi|edit|createpage|createtalk", but the UI will only show the user "Create and edit pages", because all users can read so there's no point in asking, writeapi is an implied permissions needed for edit, and createpage and createtalk are two sides of the same coin. In other words, the rationale should not be "we will confuse the user", because we decide what to show the user. It's impossible to come up with a single interface that will be perfect for both humans and bots. So what reason is there to not use actual permissions other than that reason? The approach taken in my patch may not be perfect, but at least it's > possible to fix without screwing around with the permissions structure > of the rest of MediaWiki. Putting aside the entire organization of permissions, your patch has AuthPlugin take ApiBase as a parameter, which I oppose for a completely independent reason. *-- * *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] Separation of Concerns
On 06/04/2013 06:13 PM, Tyler Romeo wrote: >>- Rollback of all the actions by an individual application should be >>possible. Yeah, if they mean a single "rollback FooApp" button, that's probably not going to happen. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Tue, Jun 4, 2013 at 7:56 PM, Tyler Romeo wrote: > Why?! What exactly is so bad about just using our own permissions, which > already exists, as the permissions for OAuth tokens. It allows the highest > level of granularity for permissions and allows us to easily display to the > user exactly what the application will be allowed to do. No, it doesn't. You think we didn't discuss this already? If you go by module, then you have problems where you need to grant specific rights for using modules like list=categorymembers and prop=revisions, but you can't grant the ability to edit normal pages without also granting the ability to edit your user CSS/JS, and (if you're an admin) the MediaWiki namespace and so on. The situation with user rights isn't any better. Editing a page requires 'edit' and 'writeapi' (and also 'read' unless you're blindly overwriting pages), and likely 'minoredit' and 'skipcaptcha' would also be wanted, and maybe also 'createpage', 'createtalk', 'autoreview', 'autopatrol', 'autoconfirmed', and 'bot'. And at the same time, you can't avoid granting the permission to write to your user CSS/JS. And using groups is worse, or else we'd wind up with a huge inflation in the number of groups defined just for OAuth purposes. And *still* you can't grant the tool permission to edit normal pages as you without allowing it to hijack your user CSS/JS. The approach taken in my patch may not be perfect, but at least it's possible to fix without screwing around with the permissions structure of the rest of MediaWiki. -- 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] Separation of Concerns
On Tue, 04 Jun 2013 17:35:24 -0700, Chris Steipp wrote: The biggest issue we hit with the permissions was trying to balance fine granularity and not overwhelming the user with the list of what was being requested and have them blindly agree to it. We initially were going to use your patch and limit based on module, but there were a few places where that seemed too course. But then if we just used user rights, then to edit a page the user needed to grant 8 (iirc) permissions. I would certainly welcome discussion on the tradeoffs. I see no problem with needing to grant 8 permissions for simple things. There is nothing inherently wrong with listing 8 strings inside of the scope you ask for. The only possible issue I can see would be the grant page overloading the user with a list of permissions. However that is only an issue if that page is implemented in a lazy way. Just dumping the permissions instead of properly formatting and grouping them. For example, assuming the rights "read, edit, autoconfirmed, createpage, createtalk, deletedhistory, deletedtext" are requested. The WRONG way to display this would be: * Read pages (read) * Edit pages (edit) * Create pages (which are not discussion pages) (createpage) * Create discussion pages (createtalk) * Edit semi-protected pages (autoconfirmed) * View deleted history entries, without their associated text (deletedhistory) * View deleted text and changes between deleted revisions (deletedtext) This set of permissions can be vastly simplified by grouping, filtering, and combining permissions. Firstly on a public wiki read can be dropped from the list. The pages are public so getting a user's read rights doesn't grant you any new permissions. Next autoconfirmed. This one you might just filter out to. Does anyone know of any situation you'd expect OAuth to let an app "Edit any page I can edit, but not the semi-protected ones I could usually edit."? edit, createpage, and createtalk can actually be grouped and combined into a single entry and group. Likewise deletedhistory and deletedtext can be combined into one entry in a separate common group. Like so: ((Grant this app permission to)) ## Editing * Edit existing content and create pages and talkpage as me. ## Administrative * View deleted history entries, text, and changes. "Edit existing content and create pages and talkpage as me." is a combination entry in the list of things being granted. The text varies by what permissions are being granted. edit,createpage,createtalk = "Edit existing content and create pages and talkpage as me." edit,createpage = "Edit existing content and create pages as me." edit,createtalk = "Edit existing content and create talkpages as me." edit = "Edit existing content as me." -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On 05/06/13 02:37, Tyler Romeo wrote: On Tue, Jun 4, 2013 at 8:35 PM, Chris Steipp wrote: We initially were going to use your patch and limit based on module, but there were a few places where that seemed too course. But then if we just used user rights, then to edit a page the user needed to grant 8 (iirc) permissions. Maybe I'm missing something, but how does editing a page require 8 permissions. Shouldn't you just need "edit"? You also need read, but that could be an "implied permission" by presenting any of the others. Chris, I would use the real permissions in the api. For user interface, they can be summarised by the user groups (as defined in the wiki), with an advanced option if you want the details. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Tue, Jun 4, 2013 at 8:35 PM, Chris Steipp wrote: > We initially were going to use your patch and limit based on module, > but there were a few places where that seemed too course. But then if > we just used user rights, then to edit a page the user needed to grant > 8 (iirc) permissions. > Maybe I'm missing something, but how does editing a page require 8 permissions. Shouldn't you just need "edit"? *-- * *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] Separation of Concerns
On Tue, Jun 4, 2013 at 4:56 PM, Tyler Romeo wrote: > On Tue, Jun 4, 2013 at 7:46 PM, Rob Lanphier wrote: > >> This page is more relevant to our immediate plans: >> https://www.mediawiki.org/wiki/Auth_systems/OAuth >> >> I would be really happy to see someone do some cleanup of this page, >> archive the bits written in 2011, and make the Auth_systems/OAuth page >> more prevalent, possibly merging with OAuth (though please don't mix >> in the obsolete stuff).. >> > > This page is, arguably, even worse. My favorite quotes from this page: > > The list of granted permissions will be supplied by the AuthPlugin > > > AuthPlugin never used to handle this kind of stuff. The only extensions > that use AuthPlugin are those that provide *supplemental* authentication > services. Notice that E:LDAPAuthentication uses AuthPlugin, but > E:TwoFactorAuthentication does not. AuthPlugin has never handled additional > authorization logic, and I don't see any reason why it should. > > >> Granted permissions are identified by string tokens. These are entirely >> independent of the existing user rights system: to successfully execute a >> module, both the existing user rights checks and the granted permissions >> check have to pass. > > > Why?! What exactly is so bad about just using our own permissions, which > already exists, as the permissions for OAuth tokens. It allows the highest > level of granularity for permissions and allows us to easily display to the > user exactly what the application will be allowed to do. The biggest issue we hit with the permissions was trying to balance fine granularity and not overwhelming the user with the list of what was being requested and have them blindly agree to it. We initially were going to use your patch and limit based on module, but there were a few places where that seemed too course. But then if we just used user rights, then to edit a page the user needed to grant 8 (iirc) permissions. I would certainly welcome discussion on the tradeoffs. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Tue, Jun 4, 2013 at 7:46 PM, Rob Lanphier wrote: > This page is more relevant to our immediate plans: > https://www.mediawiki.org/wiki/Auth_systems/OAuth > > I would be really happy to see someone do some cleanup of this page, > archive the bits written in 2011, and make the Auth_systems/OAuth page > more prevalent, possibly merging with OAuth (though please don't mix > in the obsolete stuff).. > This page is, arguably, even worse. My favorite quotes from this page: The list of granted permissions will be supplied by the AuthPlugin AuthPlugin never used to handle this kind of stuff. The only extensions that use AuthPlugin are those that provide *supplemental* authentication services. Notice that E:LDAPAuthentication uses AuthPlugin, but E:TwoFactorAuthentication does not. AuthPlugin has never handled additional authorization logic, and I don't see any reason why it should. > Granted permissions are identified by string tokens. These are entirely > independent of the existing user rights system: to successfully execute a > module, both the existing user rights checks and the granted permissions > check have to pass. Why?! What exactly is so bad about just using our own permissions, which already exists, as the permissions for OAuth tokens. It allows the highest level of granularity for permissions and allows us to easily display to the user exactly what the application will be allowed to do. *-- * *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] Separation of Concerns
On Tue, Jun 4, 2013 at 4:31 PM, Platonides wrote: > On 05/06/13 01:17, Tyler Romeo wrote: >> By saying "you can only use OAuth if you're open source", it's the same as >> saying "if you're closed source you must use insecure authentication >> methods". Because just saying OAuth must be open source isn't going to >> stop >> closed source developers. > > Yes, of course. It makes no sense. I changed it to a _should_ in the wiki > page. I just nuked it. This page is more relevant to our immediate plans: https://www.mediawiki.org/wiki/Auth_systems/OAuth I would be really happy to see someone do some cleanup of this page, archive the bits written in 2011, and make the Auth_systems/OAuth page more prevalent, possibly merging with OAuth (though please don't mix in the obsolete stuff).. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Tue, Jun 4, 2013 at 7:31 PM, Platonides wrote: > Yes, of course. It makes no sense. I changed it to a _should_ in the wiki > page Thanks. I figure it was just written quickly during brainstorming. *-- * *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] Separation of Concerns
On 05/06/13 01:17, Tyler Romeo wrote: By saying "you can only use OAuth if you're open source", it's the same as saying "if you're closed source you must use insecure authentication methods". Because just saying OAuth must be open source isn't going to stop closed source developers. Yes, of course. It makes no sense. I changed it to a _should_ in the wiki page. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Tue, Jun 4, 2013 at 7:11 PM, Mark A. Hershberger wrote: > Could you clarify this? I haven't been following this debate closely > (real life has intervened) but this seems strange to me. > > Of course, we can't control the license anyone puts on their code, but > saying that if they produce software without a BSD- or GPL-like license > then it would be insecure doesn't make sense to me. > What I meant is that right now you can make a closed source Wikipedia app. It's totally possible. All the user has to do is give the app his/her username and password and the app will do stuff. By saying "you can only use OAuth if you're open source", it's the same as saying "if you're closed source you must use insecure authentication methods". Because just saying OAuth must be open source isn't going to stop closed source developers. *-- * *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] Separation of Concerns
On 06/04/2013 06:13 PM, Tyler Romeo wrote: >>- Third party app's code *must* be free software or at least open >>source (up for debate) > > In other words, if you want to make a closed source Wikipedia app, it has > to be insecure. Could you clarify this? I haven't been following this debate closely (real life has intervened) but this seems strange to me. Of course, we can't control the license anyone puts on their code, but saying that if they produce software without a BSD- or GPL-like license then it would be insecure doesn't make sense to me. Mark. -- http://hexmode.com/ Love alone reveals the true shape of the universe. -- "Everywhere Present", Stephen Freeman ___ 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
On 04/06/13 22:29, Jeroen De Dauw wrote: > Hey, > > Because of this, I can be fairly confident in recommending thata my >> team avoids the use of TDD. >> > > Clearly you are not a fan of TDD. Which is entirely fine. If you adopt this > practice or not is a personal choice, and not one that should be forced > upon anyone. Like with all practices, effectiveness varies depending on the > people and the environment. You are however writing tests for most of your > code I hope? MediaWiki hack a serious lack of tests, and we are paying the > cost of that, if you realize this or not, so be careful with what you > recommend. The studies were comparing writing unit tests before writing code with writing unit tests after writing code. Coverage was not equivalent, but nobody is saying there should be no unit tests. My position on unit testing is like I said in my original post. I think it is essential for complex code, with decreasing gains as code becomes simpler. So I decide whether or not to write a unit test for a given module based on a cost/benefit analysis. -- 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 Tue, Jun 4, 2013 at 3:38 PM, Matthew Flaschen wrote: > See > https://www.mediawiki.org/wiki/OAuth#Suggested_Granularity_of_Permissions(list > is not final). > Who wrote this? Some interesting excerpts: > >- Third party app's code *must* be free software or at least open >source (up for debate) > > In other words, if you want to make a closed source Wikipedia app, it has to be insecure. Not the greatest strategy. >- Rollback of all the actions by an individual application should be >possible. > > Not sure how this would be implemented. Also, by the way, https://gerrit.wikimedia.org/r/20905 was merged for the purpose of enabling OAuth. The intention was just to have the extension hook into that, check for the Authorization header and validate it. *-- * *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] Architecture Guidelines: Writing Testable Code
Can you give any examples of real code that become less clear after it was rewritten for testability, and explain why it is worse after the rewrite? On Tue, Jun 4, 2013 at 7:20 PM, Marc A. Pelletier wrote: > On 06/04/2013 12:57 PM, Nikolas Everett wrote: >> The thing is quite a few of us have seen cases where people bend over >> backwards for test coverage, sacrificing code quality and writing tests >> that don't provide any real value. > > Probably better expressed than I did. > > My point is: clearly test coverage doesn't /produce/ bad code -- but > writing *for* test coverage does. Or at least, I've observed a strong > correlation between mandated test coverage metrics and code with > atrocious factorization and poor conceptual coherency. > > Tests are good. Unit testing has valuable uses in a number of cases. > Trying to universally shoehorn either into the development process is > rarely useful, and often disastrous. > > (Often, for instance, coherency of the code is sacrificed atop the altar > of separation of concerns for a vacuous gain in "testability" at the > expense of clarity). > > -- Marc > > > ___ > 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] migrating hooks doc to doxygen?
On 06/04/2013 02:03 PM, Ryan Lane wrote: > I've never understood why we have some subsection of documentation stuck in > the tree. It makes no sense. If we want to include docs with the software > shouldn't we just dump tagged docs from mediawiki.org into the tree, per > release? Right now we have docs in two places to keep up to date and > neither place is kept very well documented. I agree, it's a pain to have in both places. But I think the single place should be the source. Then, you can check that the change includes a doc update before +2'ing. It would be better to generate mediawiki.org hook docs from the source, in my opinion. Matt Flaschen ___ 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/04/2013 07:42 AM, oren bochman wrote: > This schedule is excellent news. > > I am working on integrating Moodle with mediawiki and having a Sul support > would be great. > > we are looking at two basic use cases. > 1. Allowing existing user to log into Moodle via openid. > 2. Making edits such as clearing the sandbox on behalf of students. > > Unfortunately Oauth is currently broken on the current version of Moodle and > will require some work. However I'm working on coordinating with our local > Moodle dev community to help us out. > > I am wondering if Oauth will allow a user's privileges to be queried. Or if > this can be done using the API? It can be done with the API (https://www.mediawiki.org/wiki/API:Users). However, OAuth also has a concept of scopes. So you can request a 'protect' scope, for example. You should only get it if they both have the protect right *and* choose to grant it via OAuth to your Moodle site. See https://www.mediawiki.org/wiki/OAuth#Suggested_Granularity_of_Permissions (list is not final). Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] migrating hooks doc to doxygen?
On 4 June 2013 19:00, Antoine Musso wrote: > Hello, > Thoughts ? I had taken another approach in Translate which was designed to be easy to sync to wiki: * https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FTranslate.git/2cd676fd53e4d2dd45ac22972175739f0b3e2bf0/hooks.txt * https://www.mediawiki.org/wiki/Help:Extension:Translate/Hooks -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] migrating hooks doc to doxygen?
Le 04/06/13 20:03, Ryan Lane a écrit : >> > > I've never understood why we have some subsection of documentation stuck in > the tree. It makes no sense. If we want to include docs with the software > shouldn't we just dump tagged docs from mediawiki.org into the tree, per > release? Right now we have docs in two places to keep up to date and > neither place is kept very well documented. I would myself drop the mediawiki.org documentation in favour of inline documentation which is thus kept in sync with the code. I barely update the mw.org doc when doing changes. -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] migrating hooks doc to doxygen?
On Tue, Jun 4, 2013 at 1:43 PM, Chad wrote: > On Tue, Jun 4, 2013 at 1:40 PM, Brad Jorsch wrote: > > On Tue, Jun 4, 2013 at 12:00 PM, Antoine Musso > wrote: > >> > >> Since we introduced hooks in MediaWiki, the documentation has been > >> maintained in a flat file /docs/hooks.txt . Over the week-end I have > >> converted the content of that file to let Doxygen recognize it. > >> > >> The patchset is: > >> https://gerrit.wikimedia.org/r/#/c/66128/ > > > > The result is pretty. But personally I'll probably continue to just > > look in hooks.txt if I need the info in there, and the markup in the > > (now-misnamed) file is rather ugly. Not that the existing file isn't > > also ugly, just less so. > > > > I'm with Brad. Considering we document this in the tree and on > mw.org, I'm not entirely sure what the benefit of having it done > via Doxygen is. > > I've never understood why we have some subsection of documentation stuck in the tree. It makes no sense. If we want to include docs with the software shouldn't we just dump tagged docs from mediawiki.org into the tree, per release? Right now we have docs in two places to keep up to date and neither place is kept very well documented. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] migrating hooks doc to doxygen?
On Tue, Jun 4, 2013 at 1:40 PM, Brad Jorsch wrote: > On Tue, Jun 4, 2013 at 12:00 PM, Antoine Musso wrote: >> >> Since we introduced hooks in MediaWiki, the documentation has been >> maintained in a flat file /docs/hooks.txt . Over the week-end I have >> converted the content of that file to let Doxygen recognize it. >> >> The patchset is: >> https://gerrit.wikimedia.org/r/#/c/66128/ > > The result is pretty. But personally I'll probably continue to just > look in hooks.txt if I need the info in there, and the markup in the > (now-misnamed) file is rather ugly. Not that the existing file isn't > also ugly, just less so. > I'm with Brad. Considering we document this in the tree and on mw.org, I'm not entirely sure what the benefit of having it done via Doxygen is. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] migrating hooks doc to doxygen?
On Tue, Jun 4, 2013 at 12:00 PM, Antoine Musso wrote: > > Since we introduced hooks in MediaWiki, the documentation has been > maintained in a flat file /docs/hooks.txt . Over the week-end I have > converted the content of that file to let Doxygen recognize it. > > The patchset is: > https://gerrit.wikimedia.org/r/#/c/66128/ The result is pretty. But personally I'll probably continue to just look in hooks.txt if I need the info in there, and the markup in the (now-misnamed) file is rather ugly. Not that the existing file isn't also ugly, just less so. ___ 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
On 06/04/2013 12:57 PM, Nikolas Everett wrote: > The thing is quite a few of us have seen cases where people bend over > backwards for test coverage, sacrificing code quality and writing tests > that don't provide any real value. Probably better expressed than I did. My point is: clearly test coverage doesn't /produce/ bad code -- but writing *for* test coverage does. Or at least, I've observed a strong correlation between mandated test coverage metrics and code with atrocious factorization and poor conceptual coherency. Tests are good. Unit testing has valuable uses in a number of cases. Trying to universally shoehorn either into the development process is rarely useful, and often disastrous. (Often, for instance, coherency of the code is sacrificed atop the altar of separation of concerns for a vacuous gain in "testability" at the expense of clarity). -- Marc ___ 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
Test coverage is not a quality metric, it is a quantity metric. That is it says something about the amount of tests. The coverage can say something about the overall code given that the code under test infact reflect the remaining code. As the code under test usually are better than the remaining code the overall code is usually worse than the predicted number of faults in the remaining code. My 0.05€ is to enforce testing wherever possible, possibly by using automatic gatekeepers, and also add in other quality and security metrics for the reports. Err, automated reports, that is another problem... On Tue, Jun 4, 2013 at 6:36 PM, Jeroen De Dauw wrote: > Hey, > > My own experience is that "test coverage" is a poor evaluation metric >> for anything but "test coverage"; it doesn't produce better code, and >> tends to produce code that is considerably harder to understand >> conceptually because it has been over-factorized into simple bits that >> hide the actual code and data flow. "Forest for the trees". >> > > Test coverage is a metric to see how much of your code is executed by your > tests. From this alone you cannot say if some code is good or bad. You can > have bad code with 100% coverage, and good code without any coverage. You > are first stating it is a poor metric to measure quality and then proceed > to make the claim that more coverage implies bad code. Aside from > contradicting yourself, this is pure nonsense. Perhaps you just expressed > yourself badly, as test coverage does not "produce" code to begin with. > > Cheers > > -- > Jeroen De Dauw > http://www.bn2vs.com > Don't panic. Don't be evil. ~=[,,_,,]:3 > -- > ___ > 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] Architecture Guidelines: Writing Testable Code
On Tue, Jun 4, 2013 at 12:36 PM, Jeroen De Dauw wrote: > Hey, > > My own experience is that "test coverage" is a poor evaluation metric > > for anything but "test coverage"; it doesn't produce better code, and > > tends to produce code that is considerably harder to understand > > conceptually because it has been over-factorized into simple bits that > > hide the actual code and data flow. "Forest for the trees". > > > > Test coverage is a metric to see how much of your code is executed by your > tests. From this alone you cannot say if some code is good or bad. You can > have bad code with 100% coverage, and good code without any coverage. You > are first stating it is a poor metric to measure quality and then proceed > to make the claim that more coverage implies bad code. Aside from > contradicting yourself, this is pure nonsense. Perhaps you just expressed > yourself badly, as test coverage does not "produce" code to begin with. The thing is quite a few of us have seen cases where people bend over backwards for test coverage, sacrificing code quality and writing tests that don't provide any real value. In this respect high test coverage can poison your code. It shouldn't but it can. The problem is rejecting changes like this while still encouraging people to write the useful kinds of tests - tests for usefully large chunks that serve as formal documentation. Frankly, one of my favorite tools in the world is Python's doctests because the test _is_ the documentation. Nik ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] migrating hooks doc to doxygen?
Looks pretty nice. My only complaint is that on the list page the hook header text is the same font size and weight as the "Parameters" header. I know it's indented, so you can sort of tell, but for ease of use purposes I think we should somehow change that. - The hooks are documented in a separate file (still docs/hooks.txt), > when we might want to have the doc near the wfRunHooks() call. This would be nice, but it'd have to be possible first. Not sure if Doxygen can even do that. Besides, it'd also mean the maintenance script would have to scan every file rather than just a doc/hooks.txt file. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Tue, Jun 4, 2013 at 12:00 PM, Antoine Musso wrote: > Hello, > > Since we introduced hooks in MediaWiki, the documentation has been > maintained in a flat file /docs/hooks.txt . Over the week-end I have > converted the content of that file to let Doxygen recognize it. > > The patchset is: > https://gerrit.wikimedia.org/r/#/c/66128/ > > I have used that patch to generate a temporary documentation. That lets > everyone browse the result easily. The produced result is: > > A landing page: > https://doc.wikimedia.org/mw-hooks/hooks_mainpage.html > > The doc overview: > https://doc.wikimedia.org/mw-hooks/page_hooks_documentation.html > > A list of hooks with their documentation: > https://doc.wikimedia.org/mw-hooks/page_hooks_list.html > > > I think that makes it a bit more accessible to everyone and Doxygen > autolink to referenced classes. > > Some issues I have: > > - the hooks are listed alphabetically when they could be regrouped by > theme (like API, SpecialPages, HTML Forms ...). > > - The hooks are documented in a separate file (still docs/hooks.txt), > when we might want to have the doc near the wfRunHooks() call. > > Thoughts ? > > -- > 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] Architecture Guidelines: Writing Testable Code
Hey, My own experience is that "test coverage" is a poor evaluation metric > for anything but "test coverage"; it doesn't produce better code, and > tends to produce code that is considerably harder to understand > conceptually because it has been over-factorized into simple bits that > hide the actual code and data flow. "Forest for the trees". > Test coverage is a metric to see how much of your code is executed by your tests. From this alone you cannot say if some code is good or bad. You can have bad code with 100% coverage, and good code without any coverage. You are first stating it is a poor metric to measure quality and then proceed to make the claim that more coverage implies bad code. Aside from contradicting yourself, this is pure nonsense. Perhaps you just expressed yourself badly, as test coverage does not "produce" code to begin with. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- ___ 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
On 06/04/2013 11:37 AM, John Erling Blad wrote: > It is like writing a > document with no spell checker vs using a spell checker. Which would be the right moment to remind you of the Cupertino effect that illustrates so well how the combination of automation and trust in that automation is known to cause as many (and often more insidious) problems than it solves. My own experience is that "test coverage" is a poor evaluation metric for anything but "test coverage"; it doesn't produce better code, and tends to produce code that is considerably harder to understand conceptually because it has been over-factorized into simple bits that hide the actual code and data flow. "Forest for the trees". -- Marc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] migrating hooks doc to doxygen?
Hello, Since we introduced hooks in MediaWiki, the documentation has been maintained in a flat file /docs/hooks.txt . Over the week-end I have converted the content of that file to let Doxygen recognize it. The patchset is: https://gerrit.wikimedia.org/r/#/c/66128/ I have used that patch to generate a temporary documentation. That lets everyone browse the result easily. The produced result is: A landing page: https://doc.wikimedia.org/mw-hooks/hooks_mainpage.html The doc overview: https://doc.wikimedia.org/mw-hooks/page_hooks_documentation.html A list of hooks with their documentation: https://doc.wikimedia.org/mw-hooks/page_hooks_list.html I think that makes it a bit more accessible to everyone and Doxygen autolink to referenced classes. Some issues I have: - the hooks are listed alphabetically when they could be regrouped by theme (like API, SpecialPages, HTML Forms ...). - The hooks are documented in a separate file (still docs/hooks.txt), when we might want to have the doc near the wfRunHooks() call. Thoughts ? -- Antoine "hashar" Musso ___ 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
As the dumb ass trying to merge a lot of the code last year at Wikidata I would say stop bitching about whether to make tests or not. Any tests are better than no tests, without tests merging code is pure gambling. Yes you can create a small piece of code and be fairly sure that your own code works when you merge it in, but no you can not be sure that it will continue to work when a bunch of other nerds are wild-guessing what your code is doing and then merge their own code in. It is inly one sure method to make the code keep on working and that is by adding tests. Those tests are not primarily for you, unless you do TDD, they are for everyone else. If you want some real comparison on what can be achieved with proper testing, then take a look at Coverity scan: 2012 Open Source Report [1], they are tracking 254 active projects. You must check what the projects are doing to make the code bugfree. (Amanda uses a automatic gatekeeper, and _they_have_extensive_tests_) You should not make tests that is really testing internals of an unit, you should make tests that operates on the API of the unit. You should be able to change the internals of an unit without changing the tests. If you must change the tests because of internal changes in an unit, then there is probably something wrong with the test. Security issues in an implementation is most of the time not found by unit tests, because the unit tests should test the API and not the implementation. An other thing is that if the unit test in fact tests the API the necessary seems are probably in place to do source code fault injection, and that is a very efficient tool to find security issues. Tak a look at "Software Security Assessment Tools Review" [2] for a list of proper methods for security assessment. Also tests are not a replacement for proper code review, but it will speed up the process in those cases where bugs are detected during the testing process. In some cases you can infact use the time spent on merges and the frequency whereby you break the build as a measure of how good test coverage you have. Less coverage gives higher break frequency. TDD is nice, but often it turns into testing internals of some idea the developer has, which is wrong. It also have a strange effect to create lock-in on certain solutions which can be a problem. That is you chose implementation after how easy it is to test, not how efficient the implementation is. The same thing can be said about other formal processes so I'm not sure it is a valid point. It is said that those familiar with TDD writes the tests and implementation in close to the same time as the implementation alone. Rumors has it that this comes from the fact that the prewritten tests makes the implementation more testable, and that this is an easier way than adding tests to an easier implementation later. I don't know. Code with some tests are sometimes compared to code with no tests at all, and then there are made claims that the code without tests are somehow similarly bugfree to some degree. This argument usually doesn't hold, as "some tests" isn't good enough, you need real numbers for the coverage before you can make valid claims and if the coverage is low it can be very difficult to say anything about the real effects. If you really want to make an effort to get bugfree code you need a lot of tests, above 50% and probably more like 80%. Not only do you need a lot of tests, you need a lot of people to fix those bugs, because lots of tests will find more bugs to fix. It is like writing a document with no spell checker vs using a spell checker. [1] http://www.coverity.com/library/pdf/coverity-scan-2011-open-source-integrity-report.pdf [2] http://samate.nist.gov/docs/NAVSEA-Tools-Paper-2009-03-02.pdf ___ 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
On Sat, Jun 1, 2013 at 12:14 AM, Ori Livneh wrote: > This > amounts to a workaround for git-review's tendency to frighten you into > thinking you're about to submit more patches than the ones you are working > on. > Thanks Ori, I have tested it with a couple of repositories and it works great. No more warning messages. Željko ___ 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
Hey, Because of this, I can be fairly confident in recommending thata my > team avoids the use of TDD. > Clearly you are not a fan of TDD. Which is entirely fine. If you adopt this practice or not is a personal choice, and not one that should be forced upon anyone. Like with all practices, effectiveness varies depending on the people and the environment. You are however writing tests for most of your code I hope? MediaWiki hack a serious lack of tests, and we are paying the cost of that, if you realize this or not, so be careful with what you recommend. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
This schedule is excellent news. I am working on integrating Moodle with mediawiki and having a Sul support would be great. we are looking at two basic use cases. 1. Allowing existing user to log into Moodle via openid. 2. Making edits such as clearing the sandbox on behalf of students. Unfortunately Oauth is currently broken on the current version of Moodle and will require some work. However I'm working on coordinating with our local Moodle dev community to help us out. I am wondering if Oauth will allow a user's privileges to be queried. Or if this can be done using the API? Also there unit test for the respective MW extensions ? 10x Oren Bochman Sent from my iPhone On Jun 4, 2013, at 5:43, Tyler Romeo wrote: > On Mon, Jun 3, 2013 at 8:18 PM, Chris Steipp wrote: > >> We are trying to finish the items in scope (SUL rework, OAuth, and a >> review of the OpenID extension) by the end of this month. > > Speaking of this, there's an OAuth framework attempt here: > https://gerrit.wikimedia.org/r/66286 > > Am I the only person who thinks it's a bad idea for the AuthPlugin class to > be relying on the ApiBase class for its interface? Especially since the > AuthPlugin framework isn't supposed to handle authorization logic anyway. > > *-- * > *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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
