Re: [Wikitech-l] Proposal: Wikitech contributors
Mark A. Hershberger wrote: I haven't understood the resistance of the WMF to use SMW in more places, but putting it on MW.o would really make MW.o's non-WMF focus clear. If the Wikimedia Foundation put Semantic MediaWiki on MediaWiki.org, that would mean that the Wikimedia Foundation would be committing itself to supporting it indefinitely. While there is an active Semantic MediaWiki community, this likely isn't an issue. But if, in a year or two, there's nobody else willing to help out and Semantic MediaWiki breaks, it'll be the Wikimedia Foundation's responsibility to fix MediaWiki.org. Plus there's Wikidata to consider. I can understand the hesitation here. Of course, if the WMF had some objective reason to avoid SMW, now would be a good time to clarify what those objections are. According to https://wikitech.wikimedia.org/wiki/Special:Version, the Wikimedia Foundation is now using Semantic MediaWiki (at least on a limited basis). Most of the XSS/CSRF-type security issues have been resolved at this point, I think. I think the general concern has been scalability and perhaps relatedly the ability of users to execute poorly optimized queries (maliciously or otherwise). But take this with a grain of salt as I don't follow Semantic MediaWiki very closely. Out of curiosity, what's the largest wiki to use Semantic MediaWiki? MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing the Hooks class
On Wed, 03 Apr 2013 22:23:41 -0700, Dmitriy Sintsov ques...@rambler.ru wrote: 4 Апрель 2013 г. 9:16:49 пользователь Jeroen De Dauw (jeroended...@gmail.com) написал: Hey, I see no reason to get rid of the hooks class. Given you also do not understand why I think the comment is funny, I recommend you read up on why writing static code is harmful. And on how global state can hide in static classes. We use static classes other places in core. https://yourlogicalfallacyis.com/bandwagon In almost all such cases I have seen in core this kind of use of static is bad. And there's no reason to revert to hideous functions like we had before. No one is suggesting that. Cheers -- Why the hooks should not be static? Multi-site (farm) built-in support in core without $wgConf? Common page table across multiple sites? Dmitriy How do you envision non-static hooks working and supporting multiple wikis? -- ~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] Proposal: Wikitech contributors
Hey, Out of curiosity, what's the largest wiki to use Semantic MediaWiki? That depends on how you defined largest. If you want a list of public wikis (which of course is not complete) by property value count, then here you go: http://wikiapiary.com/wiki/Semantic_statistics SMW is used on many hundreds of wikis, including those of governments and large corporations. It has been out there for years. People seem to be using it very successfully. It also has by far the largest third party community next to core itself. From my perspective a lot of the concerns typically coming from people whenever WMF usage of SMW is in question are uninformed paranoia. And there seems to be a good deal of populism going on as well, since apparently in some WMF related circles it is cool to hate SMW. See also: some testimonials: https://semantic-mediawiki.org/wiki/Testimonials Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Wikitech contributors
On Thu, Apr 4, 2013 at 2:15 AM, Jeroen De Dauw jeroended...@gmail.comwrote: Hey, Out of curiosity, what's the largest wiki to use Semantic MediaWiki? That depends on how you defined largest. If you want a list of public wikis (which of course is not complete) by property value count, then here you go: http://wikiapiary.com/wiki/Semantic_statistics SMW is used on many hundreds of wikis, including those of governments and large corporations. It has been out there for years. People seem to be using it very successfully. It also has by far the largest third party community next to core itself. From my perspective a lot of the concerns typically coming from people whenever WMF usage of SMW is in question are uninformed paranoia. And there seems to be a good deal of populism going on as well, since apparently in some WMF related circles it is cool to hate SMW. I'd say it's well informed paranoia. SMW is used on some largish wikis at Wikia and it apparently causes issues very often. The largest wiki with SMW at Wikia is very small in comparison to a lot of WMF wikis. SMW has historically had a touch of the featuritis. Most of its features would need to be disabled on WMF wikis due to performance reasons, and then what's the point? - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing the Hooks class
4 Апрель 2013 г. 10:11:44 пользователь Daniel Friesen (dan...@nadir-seen-fire.com) написал: On Wed, 03 Apr 2013 22:23:41 -0700, Dmitriy Sintsov ques...@rambler.ru wrote: 4 Апрель 2013 г. 9:16:49 пользователь Jeroen De Dauw (jeroended...@gmail.com) написал: Hey, I see no reason to get rid of the hooks class. Given you also do not understand why I think the comment is funny, I recommend you read up on why writing static code is harmful. And on how global state can hide in static classes. We use static classes other places in core. https://yourlogicalfallacyis.com/bandwagon In almost all such cases I have seen in core this kind of use of static is bad. And there's no reason to revert to hideous functions like we had before. No one is suggesting that. Cheers -- Why the hooks should not be static? Multi-site (farm) built-in support in core without $wgConf? Common page table across multiple sites? Dmitriy How do you envision non-static hooks working and supporting multiple wikis? If hooks will be non-static, should the hooks become the members of RequestContext, maybe? Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Wikitech contributors
On Wed, Apr 3, 2013 at 3:06 PM, Steven Walling steven.wall...@gmail.com wrote: The best way to approach a project like this is not to propose an up-front migration of an entire wiki to a new piece of software, just to prototype a few new features. I think the potential migration of content to wikitech and the potential use of certain MW extensions to improve the user experience are legitimately separate issues. If the migration is merited, it is likely merited irrespective of whether we use SocialProfile, LQT, SMW, SMF, etc. We could perform a large migration of content without using any of them, or we could experiment with these extensions without/before migrating any content. I'm ambivalent about the migration of content. I'm not very fond of the current division between dev-ops contributors (wikitech) and everything else (mediawiki.org), which reinforces barriers between the two worlds. Those are the barriers that Labs was designed to tear down, empowering technical contributors to prototype their changes easily, and to get them ready for large-scale usage on Wikimedia or other production sites. Having all technical contributors directed to wikitech.wikimedia.org would address that - it would introduce them to a magical world of dev-ops unicorns and PHP rainbows at the same time. And having mediawiki.org more clearly dedicated to the product would allow it to shine more brightly in its own sunflower-y colors. At the same time, the amount of wiki-ping-pong we're playing with technically interested users could very well increase significantly as a result. Right now, wikitech.wikimedia.org is relatively quiet, with changes typically either being made by the Wikimedia ops team or by Labs users. It simply stands to reason that if we distribute a lot of content from a large wiki to a much smaller one, the number of times that you'll have to go back and forth between the two to find what you're looking for will increase. API docs? Over here. Status update? Over there. Extension installation docs? Over here. Specs related to the same extension? Over there. Ping, pong. Ping, pong. The divisions may seem logical to us, but for the confused technical contributor, things could easily get a lot worse. If feasible, I would at the end of the day still argue in favor of a single consolidated technical wiki. I realize calling that wiki mediawiki.org is not ideal, but beyond the domain name, a lot can be done to provide reasonable divisions (namespaces, navigation, etc.), so that MediaWiki the product and other Wikimedia technical projects and processes are clearly distinct. Let's also not forget that we'll have future potential for new MediaWiki-related technical contribution that actually would fit very nicely under the mediawiki.org umbrella (e.g. Lua script repository, gadget repository). If we do go forward with the migration to wikitech.wikimedia.org, I would argue in favor of largely depleting mediawiki.org of content except for clearly necessary end user documentation and support pages, to minimize ping pong effects. Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Wikitech contributors
Hey, I'd say it's well informed paranoia. SMW is used on some largish wikis at Wikia and it apparently causes issues very often. The largest wiki with SMW at Wikia is very small in comparison to a lot of WMF wikis. SMW has historically had a touch of the featuritis. Most of its features would need to be disabled on WMF wikis due to performance reasons, and then what's the point? I fully agree with you when speaking about Wikipedia or whatnot. SMW, like any software, has it's issues. Knowing these I think it'd be a bad idea to try to deploy it on Wikipedia or Commons or whatever in its current state. Wikitech and MediaWiki wikis are a different story though. The ill-informed paranoia I was referring to consists out of thinking something not far from SMW will make any wiki uber-complicated and explode. This certainly does not include concerns with deployment on the big WMF project wikis, which should be taken seriously. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing the Hooks class
On Wed, 03 Apr 2013 23:43:20 -0700, Dmitriy Sintsov ques...@rambler.ru wrote: 4 Апрель 2013 г. 10:11:44 пользователь Daniel Friesen (dan...@nadir-seen-fire.com) написал: On Wed, 03 Apr 2013 22:23:41 -0700, Dmitriy Sintsov ques...@rambler.ru wrote: 4 Апрель 2013 г. 9:16:49 пользователь Jeroen De Dauw (jeroended...@gmail.com) написал: Hey, I see no reason to get rid of the hooks class. Given you also do not understand why I think the comment is funny, I recommend you read up on why writing static code is harmful. And on how global state can hide in static classes. We use static classes other places in core. https://yourlogicalfallacyis.com/bandwagon In almost all such cases I have seen in core this kind of use of staticis bad. And there's no reason to revert to hideous functions like we had before. No one is suggesting that. Cheers -- Why the hooks should not be static? Multi-site (farm) built-in supportin core without $wgConf? Common page table across multiple sites? Dmitriy How do you envision non-static hooks working and supporting multiple wikis? If hooks will be non-static, should the hooks become the members of RequestContext, maybe? Dmitriy No, hooks are not a request thing. Hooks are at a level more global than the request context and are also relevant in places where there is no request context such as maintenance scripts, parsing, and things that should be isolated and not tied to a request. RequestContext also uses the hook system. Think of it this way. A request context is for a request. Pretending we handle multiple requests in one script run we would have a separate request for each. However hooks are something done at the level of extensions. The level this part of extensions are part of is environment init, along with the loading of executable code into memory. You do this once at the start of the script execution. Not each request. If we were to run MediaWiki in a daemon like way of serving requests like python and ruby support where the application is loaded into a process and request after request is passed to it. We'd still load hooks once at the start not once per request. (and we'd probably kill off the lame stuff we have to do to avoid stuff from being initialized when it's not used in a particular request since in a daemon it's only initialized once). -- ~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] Proposal: Wikitech contributors
Thank you for the vivid discussion about the potential future roles of http://mediawiki.org and http://wikitech.wikimedia.org I have updated http://www.mediawiki.org/wiki/Technical_communications/Dev_wiki_consolidation#Proposed_solution accordingly. On 04/03/2013 03:51 PM, Steven Walling wrote: who's going to do the work of migrating all our project documentation over? guillom, myself and whoever else wants to help. http://www.mediawiki.org/wiki/Technical_communications/Dev_wiki_consolidation#Steps -- Quim Gil Technical Contributor Coordinator @ 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] Proposal: Wikitech contributors
I think we should consolidate wikitech and mediawiki. If wikipedia.org can fit all the world's knowledge, how come we can't fit all our technical know-how on one site? The fragmentation is unnecessary and arbitrary, it confuses most newcomers and those not paying attention to the proper separation between them. The site should highlight and share the technology platform used at Wikimedia Foundation. *We need a site for everyone to look at, participate in, and replicate our technology.* Replication could be anything from the most basic MW installation to a complete replica of our cluster. If we are not happy with the URL, lets come up with another one, or decide that wikitech is the preferred name, and redirect everything there. The main page would have mediawiki docs, labs, server info and stats, hackathons, apis, RFCs, and everything else related. Any non-wiki information like server health could be sub-domain of this site, possibly with extra permissions. Lets create and share a knowledge platform, not just software. /end-rant :) On Thu, Apr 4, 2013 at 3:24 AM, Quim Gil q...@wikimedia.org wrote: Thank you for the vivid discussion about the potential future roles of http://mediawiki.org and http://wikitech.wikimedia.org I have updated http://www.mediawiki.org/wiki/** Technical_communications/Dev_**wiki_consolidation#Proposed_**solutionhttp://www.mediawiki.org/wiki/Technical_communications/Dev_wiki_consolidation#Proposed_solutionaccordingly. On 04/03/2013 03:51 PM, Steven Walling wrote: who's going to do the work of migrating all our project documentation over? guillom, myself and whoever else wants to help. http://www.mediawiki.org/wiki/**Technical_communications/Dev_** wiki_consolidation#Stepshttp://www.mediawiki.org/wiki/Technical_communications/Dev_wiki_consolidation#Steps -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] Proposal: Wikitech contributors
On Thu, 04 Apr 2013 00:10:38 -0700, Erik Moeller e...@wikimedia.org wrote: I think the potential migration of content to wikitech and the potential use of certain MW extensions to improve the user experience are legitimately separate issues. Yeah. It seems like some are suggesting that some of these docs should be moved to wikitech because they would work better if SMW is available. While at the same time suggesting that not all the docs would be moved to wikitech. Which quite frankly stinks of a conflict to me. Because I can see a lot of stuff on MW.org that would be better with SMW and would fall under the banner of things that are suggested would stay on MW.org. It simply stands to reason that if we distribute a lot of content from a large wiki to a much smaller one, the number of times that you'll have to go back and forth between the two to find what you're looking for will increase. API docs? Over here. Status update? Over there. Extension installation docs? Over here. Specs related to the same extension? Over there. Ping, pong. Ping, pong. The divisions may seem logical to us, but for the confused technical contributor, things could easily get a lot worse. If feasible, I would at the end of the day still argue in favor of a single consolidated technical wiki. I realize calling that wiki mediawiki.org is not ideal, but beyond the domain name, a lot can be done to provide reasonable divisions (namespaces, navigation, etc.), so that MediaWiki the product and other Wikimedia technical projects and processes are clearly distinct. Let's also not forget that we'll have future potential for new MediaWiki-related technical contribution that actually would fit very nicely under the mediawiki.org umbrella (e.g. Lua script repository, gadget repository). +1 More things fit under the MediaWiki (and related) umbrella than many here would admit. I can understand Labs/Wikitech being another wiki for auth purposes. Like bugzilla uses another auth. But beyond that I don't like the idea of it being used to split the documentation of related things even more making it harder to find. It was hard enough eliminating the split of MediaWiki related documentation and projects onto Meta. And it STILL is. Wikidata is actually documenting a great deal of wikidata stuff including a lot of ContentHandler stuff on Meta instead of MW.org. And only putting small documentation on MW.org with almost no reference at all to the Meta pages where the original design ideas planned things. And honestly. It would be kind of nice if we could link LDAP indirectly to MW accounts. And make it easy to point MW developers on MW.org to a special page on MW.org to setup the credentials they use to log into Gerrit to commit and comment on core. -- ~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] Proposal: Wikitech contributors
On 04/03/2013 08:27 PM, Ori Livneh wrote: Before we can say anything with confidence about what newcomers truly need, we need to do some usability testing and research. Because newcomers are generally voiceless, there is an unconscious tendency to project onto them a set of subjective preferences and intuitions, and the only way around that is data. Ok, fair enough. I will have this in mind in future edits to the proposal. Help defining data points is welcome at http://www.mediawiki.org/wiki/Talk:Requests_for_comment/Wikitech_contributors#Measuring_success_25866 -- Quim Gil Technical Contributor Coordinator @ 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] Proposal: Wikitech contributors
Hi, I'm not at all concerned about the rate at which you iterate -- it isn't about how fast you put out the shiny and new, but whether the assumptions that motivate this big undertaking are testable and falsifiable. Before we can say anything with confidence about what newcomers truly need, we need to do some usability testing and research. Because newcomers are generally voiceless, there is an unconscious tendency to project onto them a set of subjective preferences and intuitions, and the only way around that is data. I don't know if this is useful in this context but because of the term usability testing I thought this extension might be interesting for you: http://www.mediawiki.org/wiki/Extension:UIFeedback This project is still under development and we haven't gotten through code and design review yet… --Claudia -- Ori Livneh ___ 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] Proposal: Wikitech contributors
On 04/04/2013 12:10 AM, Erik Moeller wrote: If the migration is merited, it is likely merited irrespective of whether we use SocialProfile, LQT, SMW, SMF, etc. In theory yes, but in practice there are some associations: * Contributors and the docs relevant for them should be in the same place. * Semantic MediaWiki is required to prototype and implement the features proposed for contributors in the quickest and simplest way. Unless someone has a better idea. * http://mediawiki.org has the docs but not SMW. * http://wikitech.wikimedia.org has SMW but not the docs. As far as I can see it is impossible to solve the puzzle without changing something and upsetting someone. The scenarios are: 1. Move the right content to Wikitech and experiment there with SMW. When Wikimedia has a better solution, take it. 2. Install SMW in mediawiki.org and experiment there. When Wikimedia has a better solution, take it. 3. Keep everything as it is. Wait for Wikidata, Flow and Global Profile to be ready to help us here. 4. Create a new website just for this. :P If you have a 5th please share it. 3 or 4 would be the usual choices out there. I believe we would be in trouble with any of both. I'm ambivalent between 1 or 2, only fearing that having so many strong opinionated positions we don't end up trying a 2.5 headed for failure (another usual choice out there). But I have hope in this discussion and our capacity to end up doing The Right Thing. -- Quim Gil Technical Contributor Coordinator @ 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] Removing the Hooks class
I still fully maintain that entirely static classes is the most useless thing and is just an extremely crude method of hiding global context. We're using PHP 5.3 in the core, might as well just use namespaces at that point, because that's what a static class is: a namespace with global variables and functions. It entirely defeats the purpose of object oriented programming. Nonetheless, I don't see any other good way to implement Hooks other than as a global state. Even though there are times where hooks are executing in a context, like Daniel said, there are times where they are not, e.g., maintenance scripts or any other place outside the normal request/response workflow. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 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] Proposal: Wikitech contributors
On 04/04/2013 03:22 AM, Jeroen De Dauw wrote: I fully agree with you when speaking about Wikipedia or whatnot. SMW, like any software, has it's issues. Knowing these I think it'd be a bad idea to try to deploy it on Wikipedia or Commons or whatever in its current state. Thank you for this. I still don't understand all the issues involved, but knowing that someone with intimate familiarity with SMW thinks it isn't appropriate for large WMF deploys helps. I'm still wondering about wikitech/MW.o, but it looks like Quim Gil has asked the SMW community for input on that front, so I'm happy. (Not that my happiness should be anyone else's goal.) Mark. -- http://hexmode.com/ [We are] immortal ... because [we have] a soul, a spirit capable of compassion and sacrifice and endurance. -- William Faulker, Nobel Prize acceptance speech ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Wikitech contributors
On 04/04/2013 03:22 AM, Jeroen De Dauw wrote: SMW will make any wiki uber-complicated and explode. This certainly does not include concerns with deployment on the big WMF project wikis, which should be taken seriously. As a point of anecdotal data, I've used SMW with success at two of my past employers for semiautomated documentation of machine rooms and related documentation. Being able to make templates (mostly autofilled by facter) that allowed queries like how much power is being used by rack C7 and what boxen are currently still running Hardy on our ops wiki, alongside the human-written documentation, was /invaluable/. This looks a lot like the scope of mwm and wikitech. So yeah; perhaps SMW has issues that makes deployment to the bigger content wikis problematic, but rejecting it for the smaller data-based ones on a kneejerk is, at best, misguided. -- Marc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Wikitech contributors
On Thu, Apr 4, 2013 at 11:59 PM, Marc A. Pelletier m...@uberbox.org wrote: So yeah; perhaps SMW has issues that makes deployment to the bigger content wikis problematic, but rejecting it for the smaller data-based ones on a kneejerk is, at best, misguided. It wasn't knee jerk the time it was discussed, and a few subsequent. There was some known problems with the code, Most of these should be cleaned up now since ryan is willing enough to run it on labs. Plus we already have another system that is getting worked on and rolled out to a few of the production wikis that will seem to do similar features (based on comments in this thread already). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Wikitech contributors
On 04/04/2013 10:04 AM, K. Peachey wrote: Plus we already have another system that is getting worked on and rolled out to a few of the production wikis that will seem to do similar features (based on comments in this thread already). I'm honestly not familiar enough with Wikidata to be able to tell how applicable it'd be to wikitech/mwm. My understanding of it is from a Wikipedia editor's point of view and I see it as The place where data is stored in a language-independent manner and can be used by all content wikis in a way that resemble SMW without redundancy. It's not clear to me that mixing our technical data with the encyclopedic data is reasonable; or that we aren't going to be causing trouble if we try. Does it support some namespace-equivalent to segregate different data sets? -- Marc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On Thu, Apr 04, 2013 at 01:51:50PM +0200, Željko Filipin wrote: A few people commented last week that they liked the charts so I have updated them to include this week's data (attached). In slight contrast, would you mind putting them on a wiki somewhere and linking to them? A) I have an email inbox quota and attachments are the first thing to go, B) Attachments of images (even small ones) on a mailing list have always seemed like a bad plan to me, C) It would be more permanent, indexable, and searchable. Thanks! -- Mark Holmquist Software Engineer 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] Taking out the garbage
On Wed, Apr 3, 2013 at 1:55 AM, Chad innocentkil...@gmail.com wrote: Hi all, tl;dr: I've cleaned up the mediawiki/core repo, and performance for fetch/clone operations should be noticeably faster. I've now done this for all other repositories, so everyone should see the benefits. I've got a change under review to add a cron to perform this weekly. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On Thu, Apr 4, 2013 at 4:04 PM, Mark Holmquist mtrac...@member.fsf.orgwrote: In slight contrast, would you mind putting them on a wiki somewhere and linking to them? Sure. Do you have a suggestion where to put them? Andre, do we already have a place for something like that? Željko ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] User signature time wrapped in a span
Yes, you would have to change it at Parser.php That point would be the appropiate one. However, given the large amount of already-posted timestamps (and that some people may not want the spans in the wiki source), why not simply use a regex to replace the dates in the page? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On 4 April 2013 15:23, Željko Filipin zfili...@wikimedia.org wrote: On Thu, Apr 4, 2013 at 4:04 PM, Mark Holmquist mtrac...@member.fsf.org wrote: In slight contrast, would you mind putting them on a wiki somewhere and linking to them? Sure. Do you have a suggestion where to put them? Andre, do we already have a place for something like that? Željko Why not just upload them as images to mediawiki.org? --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing the Hooks class
On 04.04.2013, 16:04 Tyler wrote: I still fully maintain that entirely static classes is the most useless thing and is just an extremely crude method of hiding global context. We're using PHP 5.3 in the core, might as well just use namespaces at that point, because that's what a static class is: a namespace with global variables and functions. It entirely defeats the purpose of object oriented programming. There's a difference: static classes can have private variables, allowing to hide implementation. -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing the Hooks class
On Thu, Apr 4, 2013 at 11:15 AM, Max Semenik maxsem.w...@gmail.com wrote: On 04.04.2013, 16:04 Tyler wrote: I still fully maintain that entirely static classes is the most useless thing and is just an extremely crude method of hiding global context. We're using PHP 5.3 in the core, might as well just use namespaces at that point, because that's what a static class is: a namespace with global variables and functions. It entirely defeats the purpose of object oriented programming. There's a difference: static classes can have private variables, allowing to hide implementation. And variables inside a global function are also scoped, so they don't leak implementation either. The point is semi-valid for functions, though. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Saturday: Weekend Testing Americas focusing on the new Account creation UX
You are invited to join the Weekend Testing Americas session on the new Account creation user experience: Saturday, April 6, 2013 5pm UTC - 1pm EDT - 10am PDT. http://weekendtesting.com/archives/2883 http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130406T1700 We will play with the new Account creation user experience for Wikimedia and MediaWiki sites, and also with the new Login user experience. Check the full test plan: https://www.mediawiki.org/wiki/QA/WTA_ACUX_Test_Plan_Apr_6 This event is also part of QA weekly goals. Needless to say, you are also invited to our upcoming activities. https://www.mediawiki.org/wiki/QA/Weekly_goals -- Quim Gil Technical Contributor Coordinator @ 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] Removing the Hooks class
On 04.04.2013, 19:17 Chad wrote: On Thu, Apr 4, 2013 at 11:15 AM, Max Semenik maxsem.w...@gmail.com wrote: On 04.04.2013, 16:04 Tyler wrote: I still fully maintain that entirely static classes is the most useless thing and is just an extremely crude method of hiding global context. We're using PHP 5.3 in the core, might as well just use namespaces at that point, because that's what a static class is: a namespace with global variables and functions. It entirely defeats the purpose of object oriented programming. There's a difference: static classes can have private variables, allowing to hide implementation. And variables inside a global function are also scoped, so they don't leak implementation either. The point is semi-valid for functions, though. Yeah, but what if you need more than one global function? ;) -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing the Hooks class
On Thu, Apr 4, 2013 at 11:28 AM, Max Semenik maxsem.w...@gmail.com wrote: On 04.04.2013, 19:17 Chad wrote: On Thu, Apr 4, 2013 at 11:15 AM, Max Semenik maxsem.w...@gmail.com wrote: On 04.04.2013, 16:04 Tyler wrote: I still fully maintain that entirely static classes is the most useless thing and is just an extremely crude method of hiding global context. We're using PHP 5.3 in the core, might as well just use namespaces at that point, because that's what a static class is: a namespace with global variables and functions. It entirely defeats the purpose of object oriented programming. There's a difference: static classes can have private variables, allowing to hide implementation. And variables inside a global function are also scoped, so they don't leak implementation either. The point is semi-valid for functions, though. Yeah, but what if you need more than one global function? ;) It makes it easier to support PHP4. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing the Hooks class
The case for a static class I see: Over functions: * Uses the AutoLoader when needed, no explicit require * Nicely groups the entire implementation of hooks into a compartment Over namespaced functions: * Uses the AutoLoader when needed, no explicit require * Gives us proper state across methods when we need it. Last I checked PHP does not allow namespace scoped semi-globals. -- ~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] Removing the Hooks class
On Wed, 03 Apr 2013 22:15:27 -0700, Jeroen De Dauw jeroended...@gmail.com wrote: Hey, I see no reason to get rid of the hooks class. Given you also do not understand why I think the comment is funny, I recommend you read up on why writing static code is harmful. And on how global state can hide in static classes. Maybe you should try linking to a specific reason. I understand perfectly fine that globals and static classes both have global state. But I also understand that classes even when static still have advantages over functions and global variables. Hook registration is a matter of connecting core code paths to extension code paths. It is pretty much inherently a static operation. I was also trying to make sure that you were in fact commenting on globals are evil and not mistaking Used to supersede $wgHooks for something like This was written to supersede $wgHooks but no-one uses it so it doesn't supersede $wgHooks anymore. We use static classes other places in core. https://yourlogicalfallacyis.com/bandwagon In almost all such cases I have seen in core this kind of use of static is bad. Linker, Html, and Xml included? MWNamespace could use some instance methods. But registering hooks is pretty much a static operation when extensions themselves are basically static things that we don't load as an instance. In any case you're cherry picking sentences from a paragraph of things that belong together. That borders on https://yourlogicalfallacyis.com/strawman and maybe https://yourlogicalfallacyis.com/the-fallacy-fallacy I never implied that just because we use static classes elsewhere in core that it alone was a reason to use a static class. We use static classes other places in core. And there's no reason to revert to hideous functions like we had before. Was supposed to be read together. And was meant to indicate that using static methods instead of functions is not out of step with our coding guidelines. And there's no reason to revert to hideous functions like we had before. No one is suggesting that. Then instead of talking about removing the Hooks class why don't you try instead talking about what kind of hooks system we should create to supersede the Hooks class. Usually when someone talks about deprecating and removing something static that replaces something static they're not talking about replacing it with something non-static. Nothing about your message read as Lets replace Hooks with something non-static. It read much more clearly as No one is using Hooks, how about we kill it. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- ~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] Removing the Hooks class
On Wed, 03 Apr 2013 22:15:27 -0700, Jeroen De Dauw jeroended...@gmail.com wrote: Hey, I see no reason to get rid of the hooks class. Given you also do not understand why I think the comment is funny, I recommend you read up on why writing static code is harmful. And on how global state can hide in static classes. Maybe you should try linking to a specific reason. I understand perfectly fine that globals and static classes both have global state. But I also understand that classes even when static still have advantages over functions and global variables. Hook registration is a matter of connecting core code paths to extension code paths. It is pretty much inherently a static operation. I was also trying to make sure that you were in fact commenting on globals are evil and not mistaking Used to supersede $wgHooks for something like This was written to supersede $wgHooks but no-one uses it so it doesn't supersede $wgHooks anymore. We use static classes other places in core. https://yourlogicalfallacyis.com/bandwagon In almost all such cases I have seen in core this kind of use of static is bad. Linker, Html, and Xml included? MWNamespace could use some instance methods. But registering hooks is pretty much a static operation when extensions themselves are basically static things that we don't load as an instance. In any case you're cherry picking sentences from a paragraph of things that belong together. That borders on https://yourlogicalfallacyis.com/strawman and maybe https://yourlogicalfallacyis.com/the-fallacy-fallacy I never implied that just because we use static classes elsewhere in core that it alone was a reason to use a static class. We use static classes other places in core. And there's no reason to revert to hideous functions like we had before. Was supposed to be read together. And was meant to indicate that using static methods instead of functions is not out of step with our coding guidelines. And there's no reason to revert to hideous functions like we had before. No one is suggesting that. Then instead of talking about removing the Hooks class why don't you try instead talking about what kind of hooks system we should create to supersede the Hooks class. Usually when someone talks about deprecating and removing something static that replaces something static they're not talking about replacing it with something non-static. Nothing about your message read as Lets replace Hooks with something non-static. It read much more clearly as No one is using Hooks, how about we kill it. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- ~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] User signature time wrapped in a span
On Wed, Apr 3, 2013 at 4:15 PM, Daniel Friesen dan...@nadir-seen-fire.comwrote: On Wed, 03 Apr 2013 15:34:28 -0700, Brion Vibber br...@pobox.com wrote: Parsing the timestamps in the text is a bit tough as it may be different in different languages my recommendation is to include a 'data-timestamp' attribute on that span and put in a language-independent machine-readable timestamp format. Note that if HTML5 is enabled on a wiki we should already support the basic time element. http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element Niiice. That's better than a custom attribute, yes. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On 04/04/2013 07:23 AM, Željko Filipin wrote: On Thu, Apr 4, 2013 at 4:04 PM, Mark Holmquist mtrac...@member.fsf.orgwrote: In slight contrast, would you mind putting them on a wiki somewhere and linking to them? Sure. Do you have a suggestion where to put them? Somewhere near http://www.mediawiki.org/wiki/Community_metrics would be good. We are also aiming to have nice Bugzilla charts integrated one day with MediaWiki - see / watch / contribute features requests, testing or code or code to http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Productize_the_Bugzilla-MediaWiki_extension https://github.com/mozilla/mediawiki-bugzilla https://bugzilla.wikimedia.org/show_bug.cgi?id=27001#c21 -- Quim Gil Technical Contributor Coordinator @ 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] Removing the Hooks class
Hey, I'm curious what the list thinks of deprecating and eventually removing the Hooks class. Some relevant info: /** * Hooks class. * * Used to supersede $wgHooks, because globals are EVIL. * * @since 1.18 */ https://github.com/wikimedia/mediawiki-core/blob/master/includes/Hooks.php#L30 I personally find the comment hilarious and hope you see why when looking at the class. Looks like usage in core and extensions is not to extensive, so switching to something more sane seems quite feasible. I second that! Also I have an idea: maybe it would be good for mediawiki it the initialisation state along with all constants/global variables/extension metadata/preinitialised parser/preloaded PHP files, could be cached somewhere as the whole and just loaded on each request instead of being sequentially initialised? (extension metadata = hooks/special pages/i18n files/resource modules/credits/etc) If it's a good idea then I think sequential setting of hooks via a method call is not that good? (because hooks become even less declarative?) Or it's not worth it and the initialisation overhead is small? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Wikitech contributors
Keeping a single wiki seems to be the most sensible approach. I agree with Erik that there are good ways to separate different types of content, such as namespaces, and I agree with Yuri that wikitech is the best choice of name, since it is a superset of mediawiki. I think we should agree on this first, and then decide whether we want the more ambitious, SMW-powered features (I am for them as well, btw). --Waldir On Thu, Apr 4, 2013 at 8:10 AM, Erik Moeller e...@wikimedia.org wrote: If feasible, I would at the end of the day still argue in favor of a single consolidated technical wiki. I realize calling that wiki mediawiki.org is not ideal, but beyond the domain name, a lot can be done to provide reasonable divisions (namespaces, navigation, etc.), so that MediaWiki the product and other Wikimedia technical projects and processes are clearly distinct. On Thu, Apr 4, 2013 at 8:58 AM, Yuri Astrakhan yastrak...@wikimedia.org wrote: If we are not happy with the URL, lets come up with another one, or decide that wikitech is the preferred name, and redirect everything there. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing the Hooks class
On Thu, 04 Apr 2013 13:57:42 -0700, vita...@yourcmc.ru wrote: I second that! Also I have an idea: maybe it would be good for mediawiki it the initialisation state along with all constants/global variables/extension metadata/preinitialised parser/preloaded PHP files, could be cached somewhere as the whole and just loaded on each request instead of being sequentially initialised? (extension metadata = hooks/special pages/i18n files/resource modules/credits/etc) If it's a good idea then I think sequential setting of hooks via a method call is not that good? (because hooks become even less declarative?) Or it's not worth it and the initialisation overhead is small? You can't cache program state and loaded code like that in PHP. We explicitly have to abuse the autoloader and develop other patterns to avoid loading unused portions of code because if we don't our initialization is unreasonably long. In other languages of course like python and ruby. The application runs more like a daemon. Initialization can be done once when the program starts up. Then many requests are handled by the same process. But PHP pretends to be CGI even when not CGI. HipHop is an improvement. But we're not quite there yet and most people probably won't try using it or need it. -- ~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] Taking out the garbage
Hey, I've now done this for all other repositories, so everyone should see the benefits. I've got a change under review to add a cron to perform this weekly. Thanks Chad! You win one free interwebs! Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Registering PHPUnit tests from third party libraries
Hey, I have some extensions that make use of non-MW dependent PHP libraries. These libraries come with PHPUnit tests that can be run as standalone. I'd like them to be run together with the tests for my extensions making use of them whenever I run them using phase3/tests/phpunit/phpunit.php. So far I have been doing this by registering the tests via the UnitTestsList hook as if they where regular extension tests. This is not ideal though since then I need to maintain this list of tests and make sure I update it whenever the third party library changes. The library itself does not provide a list of test files, as it's runner just runs everything in the relevant test directory, much like as MW does for core tests. Clearly that is not ideal, so I am looking for a way to not have to maintain such lists. Is there a way to register a whole directory so that the MW phpunit.php script runs all the tests in it? Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Obtaining the latest commits
Hey, I am looking for a way to obtain some information on the commits made to some WMF hosted git repo within the last n seconds. My current solution is using githubs since parameters as follows: https://api.github.com/repos/wikimedia/mediawiki-extensions-Wikibase/commits?since=2013-04-05T04:17:03Z This however does not really work for me since there is a lag of a minute or two before the commit gets pushed to github. So if I ask for the commits made in the last 30 seconds, I will never get anything back. Is there a similar API in gitweb, gerrit or something else accessible over http? Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
