Re: [Wikitech-l] wfRunHooks deprecation
Hey, Does the new syntax offer any advantage over the old one? Assuming that we want to switch to non-static function calls eventually (which I hope is the case), wouldn't it be friendlier towards extension maintainers to only deprecate once we are there, instead of forcing them to update twice? Good points and questions. While this deprecation is not as problematic as simply ditching the current hook system altogether, it does indeed seem a bit of busy work. The Hooks class has this comment Used to supersede $wgHooks, because globals are EVIL., which is quite amusing if you consider all fields and methods are static. So it's a switch from a global var to a global field, thus adding a second global to get rid of the first one. I have this presentation on static code which has a screenshot of this comment and class in it :) Cheers -- Jeroen De Dauw - http://www.bn2vs.com Software craftsmanship advocate Evil software architect at Wikimedia Germany ~=[,,_,,]:3 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: No more Architecture Committee?
On Fri, Jan 16, 2015 at 5:04 AM, Rob Lanphier ro...@wikimedia.org wrote: Do we need a BFDL? On Fri, Jan 16, 2015 at 8:18 AM, Erik Moeller e...@wikimedia.org wrote: Within the organizational pattern we use, the way to complement Damon's and my roles is usually with a CTO On Fri, Jan 16, 2015 at 7:57 AM, Tim Starling tstarl...@wikimedia.org wrote: The problem is that the (Architecture Committee) work is mostly administrative and not empowered. Committee members are skeptical of many of the current ideas floating around at the moment, and have their own ideas about what things should be priorities, but have no expectation that those ideas will be considered for resourcing. (...) It's not a community open source project, it is an engineering organisation with a strict hierarchy. We don't have a BDFL, we have a VPE. We need a healthy MediaWiki open source software project in the first place. Without this, no committee, dictator or CTO will save the project in the long run. And Wikimedia works for the long run. Wikimedia is a movement and MediaWiki is an open source software project. While the Wikimedia Foundation plays a key role in the development of MediaWiki, the structure of the open source project must be driven by community merit. The MediaWiki platform roadmap should be discussed and agreed at a community level. Resourcing should be a consequence of technical agreement, not the cause. Project roles should be a consequence of project merit, not the cause. The WMF Engineering structure should support and complement the MediaWiki OSS community structure, not replace it. The five people forming the Architecture Committee are in a privileged position, receiving the support from the MediaWiki developer community and the WMF Engineering management. I don't think dismantling this team is a good idea both in terms of open source project and WMF competence and health, no matter how problematic the current situation is. The rest of us should help moving the current situation forward, not backward. Tim identifies lack of empowerment and top-down WMF management as key problems. Opinions might differ interpreting the current situation, but I guess all of us agree that an architecture committee can only work if they are empowered to be co-pilots of the MediaWiki platform roadmap. However, it is true that the current situation is not sustainable. The ArchCom is not directly active in the WMF quarterly planning (some of its members take part, but they do it mainly because of their WMF individual roles). Meanwhile, most of the ArchCom work goes to administrative work and RfC discussions that are not among the top priorities of the project. A missed opportunity, certainly. The first steps to fix this problem could be: * Identification of key MediaWiki platform areas and their architects / maintainers. Currently MediaWiki Core has no less than 210 components identified at https://www.mediawiki.org/wiki/Developers/Maintainers . We should have just a handful of areas covering all these components, with owners identified and empowered to keep their area tidy and build the roadmap with the rest of architects. * Prioritization of architecture topics, so we all agree at least on what is urgent/important. https://phabricator.wikimedia.org/tag/architecture/ and https://phabricator.wikimedia.org/tag/mw-rfcs/ are a step forward, but they still don't reflect the priorities needed. If the current ArchCom grows to include the architects of MediaWiki areas, and if this wider team gets regularly involved in prioritization of architecture tasks, RfC discussions, and WMF platform planning... probably we will go in the direction we want this big software project to go. Only then I would start discussing the need of a BFDL or a CTO. Considering the appointment of one of these roles before addressing the core of the problem would put us more in a compromise, imho. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] wfRunHooks deprecation
On Jan 21, 2015 1:40 PM, Jeroen De Dauw jeroended...@gmail.com wrote: Hey, Does the new syntax offer any advantage over the old one? Assuming that we want to switch to non-static function calls eventually (which I hope is the case), wouldn't it be friendlier towards extension maintainers to only deprecate once we are there, instead of forcing them to update twice? Good points and questions. While this deprecation is not as problematic as simply ditching the current hook system altogether, it does indeed seem a bit of busy work. The Hooks class has this comment Used to supersede $wgHooks, because globals are EVIL., which is quite amusing if you consider all fields and methods are static. So it's a switch from a global var to a global field, thus adding a second global to get rid of the first one. I have this presentation on static code which has a screenshot of this comment and class in it :) Cheers -- Jeroen De Dauw - http://www.bn2vs.com Software craftsmanship advocate Evil software architect at Wikimedia Germany ~=[,,_,,]:3 Ill be honest i dont understand the point of deprecating that. As you say the evil globalness is the same amount of evil regardless of the type of global symbol. And really i dont think global hooks causes too many problems. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] VE without Parsoid
James Forrester jforres...@wikimedia.org writes: There's also #3 – doing all the dozens of things that the wikitext parser does on ingestion. All the redlinks and categories tables, building a user-land (not UI) HTML template system for transclusions, media updates, *etc.* Not a trivial task. If I'm not mistaken, the MW Parser already does thos and Parsoid relies on MW for this. So assuming we can go from Wikitext - HTML (we already can) and HTML - Wikitext (which is, AFAICT, what we would need a PHP implementation of) then we're golden! Mark. -- Mark A. Hershberger NicheWork LLC 717-271-1084 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: No more Architecture Committee?
Quim Gil q...@wikimedia.org writes: We need a healthy MediaWiki open source software project in the first place. Without this, no committee, dictator or CTO will save the project in the long run. Agreed. While the Wikimedia Foundation plays a key role in the development of MediaWiki, the structure of the open source project must be driven by community merit. The MediaWiki platform roadmap should be discussed and agreed at a community level. Thank you for saying this. You also re-iterated Tim's point about ArchCom's powerlessness and pointed to some ways to address that. I would also suggest that an effort be made to find community members who are not WMF employees to participate in the ArchCom and then to have their voices heard during in quarterly planning. You also suggested that we [identify] key MediaWiki platform areas and their architects / maintainers. If we look at the whole MW ecosystem, I sure we'll find that some key platform areas have maintainers who are not WMF employees. Mark. -- Mark A. Hershberger NicheWork LLC 717-271-1084 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] wfRunHooks deprecation
They probably could turn that global class into facade - compact form of IoC container Laravel framework uses. Dmitriy On Thu, Jan 22, 2015 at 12:51 AM, Brian Wolff bawo...@gmail.com wrote: On Jan 21, 2015 1:40 PM, Jeroen De Dauw jeroended...@gmail.com wrote: Hey, Does the new syntax offer any advantage over the old one? Assuming that we want to switch to non-static function calls eventually (which I hope is the case), wouldn't it be friendlier towards extension maintainers to only deprecate once we are there, instead of forcing them to update twice? Good points and questions. While this deprecation is not as problematic as simply ditching the current hook system altogether, it does indeed seem a bit of busy work. The Hooks class has this comment Used to supersede $wgHooks, because globals are EVIL., which is quite amusing if you consider all fields and methods are static. So it's a switch from a global var to a global field, thus adding a second global to get rid of the first one. I have this presentation on static code which has a screenshot of this comment and class in it :) Cheers -- Jeroen De Dauw - http://www.bn2vs.com Software craftsmanship advocate Evil software architect at Wikimedia Germany ~=[,,_,,]:3 Ill be honest i dont understand the point of deprecating that. As you say the evil globalness is the same amount of evil regardless of the type of global symbol. And really i dont think global hooks causes too many problems. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] new extension
Il 21/01/2015 05:27, Gergo Tisza ha scritto: On Mon, Jan 19, 2015 at 10:00 AM, Tyler Romeo tylerro...@gmail.com wrote: * Do you think the extension should use the extmetadata property of ApiQueryImageInfo instead of a its own module? * Is it advisable to store validation data permanently in the database? I have no idea about this, but it does seem that the metadata is propagated to the oldimage table when a new one is uploaded, so it would fulfill your above question about storing old revisions' validation status. metadata is data generated from the file. It has built-in storage and invalidation mechanisms that are based on file upload / purge. extmetadata is assumed to come from some other source, and providers need to handle invalidation (and permanent storage, if desirable) manually. Thus, metadata would be a better fit in theory, but I don't think it offers any mechanism currently for extensions to hook into it. So I don't think you are any worse off by writing a self-contained extension. There is the GetExtendedMetadata hook https://www.mediawiki.org/wiki/Manual:Hooks/GetExtendedMetadata but, according to the documentation https://www.mediawiki.org/wiki/API:Properties#imageinfo_.2F_ii, the data should be in HTML format. ___ 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] Announcement: Chad Horohoe joins the Release Engineering team
On Tue, Jan 20, 2015 at 11:39 PM, Greg Grossmeier g...@wikimedia.org wrote: I'm entirely pleased to announce that Chad Horohoe is joining the Wikimedia Foundation's Release Engineering Team. I'll confess that Chad is one of my barometers and role models in the Wikimedia movement. In my experience, not only it is useful to know whether Chad agrees or disagrees on something, it is even more useful to learn why and to see how he expresses his opinion. With these qualities, he will be a very useful team member anywhere. As we can see from the ongoing discussions, now is a very good time to add more brain and hands to MediaWiki releases. Congratulations and thank you for your work. PS: and then the move of Brion back to MediaWiki Core... the pieces are fitting almost magically! -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Congratulations to MediaWiki Farmers User Group for being approved as a Wikimedia User Group
On Tue, Jan 20, 2015 at 9:41 PM, Legoktm legoktm.wikipe...@gmail.com wrote: Please join the Affiliations Committee in congratulating the MediaWiki Farmers User Group on their official approval as a Wikimedia User Group: https://meta.wikimedia.org/wiki/Affiliations_Committee/Resolutions/MediaWiki_Farmers_User_Group_-_Liaison_approval,_January_2015 I didn't see this one coming! Excellent idea, and a great complement to the MediaWiki Stakeholders group. Wikimedia-as-a-farm should be represented in this group officially, in addition with the personal interest that some WMF employees might have on this topic. While we might discuss whether some MediaWiki-for-third-parties use cases might be relevant to Wikimedia plans, the feedback and plans of third party MediaWiki farms should be fully aligned with the Wikimedia plans -- and vice versa. https://www.mediawiki.org/wiki/Project:MediaWiki_Farmers_user_group#Members -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
