Re: [Wikitech-l] RFC: Refactoring the Title object
On 25/10/13 03:32, Daniel Friesen wrote: On 2013-10-24 9:19 AM, Brad Jorsch (Anomie) wrote: The claimed problem behind a lot of this is too many dependencies making things hard to test and the idea that you can somehow make this go away by dividing everything into tinier and tinier pieces. To some extent this works, but at the cost of making the system as a whole harder to understand because you have to track all the little pieces. I doubt MediaWiki has reached the point of diminishing returns on that, but I'm not really sure that the end-goal envisioned here is the *right* division. Then there's the potential that individually testing a bunch of components doesn't always match what happens in the actually used code that puts everything together. So in the end you either have to also test the thing as a whole anyways. Or you end up with unit tests that are even less useful than you started because they won't catch regressions they would've originally. Intuitively, it seems likely that if we reduce the typical scope and integration level of automated testing, we will end up missing bugs, because bugs which were previously testable due to being within a single unit will now be spread over multiple units. Presumably this effect is offset by an increase in test coverage. However, I would prefer not to make such decisions by intuition alone. It would be nice to see some solid statistical data on this. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Page title length
Reposted to https://www.mediawiki.org/wiki/Page_title_size_limitations . Thank you very much Nathan, Brion and Daniel for your research and good advices! It seems indeed more complex that I naively thought, but I'll try to make the changes you advised soon, keeping track of everything so that a good recipe can be written. Should I open a bugreport about this? Thank you, -- Elie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On Mon, Oct 14, 2013 at 5:00 AM, reporter repor...@kaulen.wikimedia.orgwrote: Top 5 bug report closers lydia.pintscher [AT] wikimedia66 jforrester [AT] wikimedia.org 26 tomasz [AT] twkozlowski.net 21 jrobson [AT] wikimedia.org16 marc [AT] uberbox.org 11 Would anybody else like to see Top 5 bug report creators list, or is it just me? Željko ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Design] Visualising CSS debt - cleaning up our messy codebase
On 10/25/2013 02:51 AM, Jared Zimmerman wrote: Matt, we're not planning on getting rid of blue buttons but the colors will now have meaning, and since this is a one step action (send a password reset email) it gets a green button here. I see, my mistake. I unintentionally exaggerated the semantic changes you're making. The colors do have meaning already, though the well-known blue button has somewhat orthogonal semantics. mw-ui-primary is currently the key (primary) button of a form, e.g. Log in. That translates to blue in Vector, and is the one currently used on Login and Signup. mw-ui-constructive is green, and mw-ui-destrructive is read (roughly the same as the proposed standard, though the appearance is different). Blue = Progressive (more steps in the process) Green = Constructive/Completion (only/final step in a process) Red = Destructive Still, that is a change in usage. It means both the login and signup will be green, for starters. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Code Climate for Ruby and JavaScript
I have set up Code Climate[1] for a few WMF repositories that have Ruby code[2] but looks like it created JavaScript reports[3] (instead of Ruby) for a few repositories[4][5]. There are a few interesting Ruby reports[6][7][8]. Željko -- 1: https://codeclimate.com/ 2: https://github.com/wikimedia/mediawiki-selenium 3: http://blog.codeclimate.com/blog/2013/10/24/code-climate-for-javascript/ 4: https://codeclimate.com/github/wikimedia/mediawiki-extensions-UniversalLanguageSelector 5: https://codeclimate.com/github/wikimedia/mediawiki-extensions-VisualEditor 6: https://codeclimate.com/github/wikimedia/mediawiki-extensions-MobileFrontend 7: https://codeclimate.com/github/wikimedia/mediawiki-extensions-Wikibase 8: https://codeclimate.com/github/wikimedia/qa-browsertests ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code Climate for Ruby and JavaScript
God I hate Ruby, but the JS reports look interesting, albeit it's kind of just JSHint in a nicer GUI with some cyclomatic complexity checks. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science On Fri, Oct 25, 2013 at 7:38 AM, Željko Filipin zfili...@wikimedia.orgwrote: I have set up Code Climate[1] for a few WMF repositories that have Ruby code[2] but looks like it created JavaScript reports[3] (instead of Ruby) for a few repositories[4][5]. There are a few interesting Ruby reports[6][7][8]. Željko -- 1: https://codeclimate.com/ 2: https://github.com/wikimedia/mediawiki-selenium 3: http://blog.codeclimate.com/blog/2013/10/24/code-climate-for-javascript/ 4: https://codeclimate.com/github/wikimedia/mediawiki-extensions-UniversalLanguageSelector 5: https://codeclimate.com/github/wikimedia/mediawiki-extensions-VisualEditor 6: https://codeclimate.com/github/wikimedia/mediawiki-extensions-MobileFrontend 7: https://codeclimate.com/github/wikimedia/mediawiki-extensions-Wikibase 8: https://codeclimate.com/github/wikimedia/qa-browsertests ___ 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] Visualising CSS debt - cleaning up our messy codebase
Le 24/10/13 23:43, Jon Robson a écrit : I think we are all in agreement that the CSS in MediaWiki is a mess but it's not clear how to solve the mess. I think I've created a useful bit of JS to visualise this mess and make a path to solving it clearer. If you visit: http://jonrobson.me.uk/lsg/ You will see in the dropdown mediawiki vector styles. This is a CSS file I created by manually concatenating all CSS files loaded by default on desktop. snip Is there any CSS linting utility to catch them ? If not, it would be nice to be able to run that kind of checks via Jenkins whenever someone send a patchset. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC: Refactoring the Title object
Le 25/10/13 07:55, Tim Starling a écrit : Since the Title class is large to start with (4895 lines) I figure it can tolerate being cut up a few times without the resulting pieces becoming tiny. So, it makes an interesting test case for the approach. We will see the consequences with more clarity once the code reaches Gerrit for review, if we allow it to proceed that far. Would it make sense to cut a TitleValue branch as a playground? If we can get some code before the January summit, that would give us all a bit more experience. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code Climate for Ruby and JavaScript
On Fri, Oct 25, 2013 at 1:51 PM, Tyler Romeo tylerro...@gmail.com wrote: God I hate Ruby Was this really necessary? Željko ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code Climate for Ruby and JavaScript
Hey, That's very interesting, thanks for sharing. This service looks very similar to Scrutinizer, which we are using for some the of Wikidata related PHP components. https://scrutinizer-ci.com/g/wikimedia/mediawiki-extensions-WikibaseDatabase/ 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] Bugzilla Weekly Report
On 10/25/2013 04:28 AM, Željko Filipin wrote: Would anybody else like to see Top 5 bug report creators list, or is it just me? I would! -- 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] Page title length
Search around for '255' appearing in .php, .inc, or .js files and change the checks to 1023. [...] Should someone maybe define a constant Title::MAX_LENGTH instead of hard-coding 255 in many PHP files? DanB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Page title length
On Fri, Oct 25, 2013 at 8:19 AM, Daniel Barrett d...@vistaprint.com wrote: Search around for '255' appearing in .php, .inc, or .js files and change the checks to 1023. [...] Should someone maybe define a constant Title::MAX_LENGTH instead of hard-coding 255 in many PHP files? Yes, such a thing should be done. :) We'll also have to find a way to export the value to JavaScript and to SQL. JS can probably use a global config var or such; SQL can probably use a magic comment+token replacement like the db type and prefix magic. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTTP Archive now tracking several Wikimedia wikis
On Friday, October 25, 2013, Bartosz Dziewoński wrote: On Fri, 25 Oct 2013 01:20:41 +0200, Matthew Flaschen mflasc...@wikimedia.org wrote: This is is very interesting. It seems like we should be able to pull that 1.3 MB down a bit (I don't think that takes into account gzip, but I'm not sure). jquery.ui would be a start (it's not actually used on the main page, but it's loaded). See https://bugzilla.wikimedia.** org/show_bug.cgi?id=0https://bugzilla.wikimedia.org/show_bug.cgi?id=0 Out of that 1.3 MB, ULS fonts contribute to almost a megabyte (search the waterfall for 'amiri'). How was it ever considered acceptable to deploy this is beyond me. This will be reduced drastically in our upcoming deployment[1]. The fonts were used for displaying Arabic written on the page. Using a complete font for language autonyms is not a good idea considering the bandwidth, but without compromising on readability of our large number of supported languages, a subset font is going to be applied with less than 50KB size. More at https://www.mediawiki.org/wiki/UniversalLanguageSelector/AutonymFont [1] https://www.mediawiki.org/wiki/MediaWiki_1.23/wmf1#UniversalLanguageSelector and https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap Already available at MediaWiki.org; testwiki; test2wiki; testwikidatawiki; loginwiki Thanks Santhosh ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code Climate for Ruby and JavaScript
On 25 October 2013 04:38, Željko Filipin zfili...@wikimedia.org wrote: I have set up Code Climate[1] for a few WMF repositories that have Ruby code[2] but looks like it created JavaScript reports[3] (instead of Ruby) for a few repositories[4][5]. There are a few interesting Ruby reports[6][7][8]. Željko -- 1: https://codeclimate.com/ [Snip] 5: https://codeclimate.com/github/wikimedia/mediawiki-extensions-VisualEditor This is interesting - thanks! A nice hit-list to consider for VE technical debt (even if a bunch of it is third-party libraries that can't be excluded yet). J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Visualising CSS debt - cleaning up our messy codebase
On 24 October 2013 18:12, Matthew Flaschen mflasc...@wikimedia.org wrote: VE has special issues since they want it to be usable as a stand-alone editor, but they are making progress in factoring out oojs-ui (a new UI library) from ve.ui (https://gerrit.wikimedia.org/**r/#/c/88896/https://gerrit.wikimedia.org/r/#/c/88896/). I think they are interesting in making mediawiki.ui a custom layer on top of the more general oojs-ui library (kind of like you can have jquery ui themes. but probably with significant differences in the details). Yeah, we're very keen on our work being useful for other teams. An mw.ui layer on top of oojs-ui is very much an objective, and the ability to theme/skin/etc. that (so that Agora/whatever changes can be applied system-wide in one go). The commit above should get merged in the next day or so; the next step is to move it into MW core, as part of the Great VisualEditor Repo Split of 2013. :-) This part is probably the most up in the air, and would be good to discuss at the architecture summit, among other places. Well, hopefully we'll have made some actual implementation progress by January, but yes, very much a worthwhile thing to discuss there. I suppose we'll need to go away and write up an RfC, once we actually know what the proposal is having tried some things out in practice. J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On Fri, 2013-10-25 at 10:28 +0200, Željko Filipin wrote: Would anybody else like to see Top 5 bug report creators list, or is it just me? Feel free to file an enhancement request at http://bugzilla.wikimedia.org/enter_bug.cgi?product=Wikimediacomponent=Bugzilla And if somebody feels like hacking, the code is at operations/puppet.git/templates/misc/bugzilla_report.php andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On 10/25/2013 01:28 AM, Željko Filipin wrote: Would anybody else like to see Top 5 bug report creators list, or is it just me? See Top closers and Top openers of all-time, last year and last month at http://korma.wmflabs.org/browser/top.html PS: yes, this information should appear at http://korma.wmflabs.org/browser/its.html - I will file a report. -- 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] FOSS Outreach Program for Women: call for candidates, projects, and mentors
After a quick survey through the main teams involved in the Summer round of OPW and Google Summer of Code, it is clear that most of them need a rest. This is a good chance for new mentors and projects to join in! I'm pinging other Wmikimedia Foundation teams e.g. Analytics, which already have committed to bring a proposal and two mentors. What about projects like Commons, Wikinews, Wikivoyage...? What about bots, gadgets, templates...? What about mobile apps not supported by the WMF mobile team...? What about mediawiki.org and wikitech.wikimedia.org...? Are there any technical projects that tech events organizers could benefit from...? On 10/24/2013 03:02 PM, Quim Gil wrote: https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects New projects and mentors are welcome too, of course! When thinking about project proposals, a good rule of thumb is: tasks that would take two weeks of full time work to an experienced contributor. We found that these two weeks can be translated in approximately six weeks of an intern. This time is easily wrapped with as much time or more for onboarding to open source development and the Wikimedia tech community, setting up your environment and tools, testing, bugfixing, documentation and deployment. If you are interested, we have documented more lessons learned at https://www.mediawiki.org/wiki/Mentorship_programs/Lessons_learned -- 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
[Wikitech-l] Deployment highlights - week of October 28th
Hello and welcome to the latest edition of the WMF deployment highlights. The full list of planned deployments can be found here: https://wikitech.wikimedia.org/wiki/Deployments#Next_Week And for a look of what is on the horizon, see: https://wikitech.wikimedia.org/wiki/Deployments#Next_Month Here are the highlights: == Sometime early week == * We'll begin serving Oceania traffic for Wikipedias from the newly deployed San Francisco caching datacenter. There should not be any downtime but please let us know if you live in the region commonly referred to as Oceania (https://en.wikipedia.org/wiki/Oceania) and experience any issues. == Monday == * Deploy of the Redis-based Federated JobQueue https://bugzilla.wikimedia.org/show_bug.cgi?id=49788 * MediaWiki 1.23wmf1 to all non-Wikipedia sites https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap#Schedule_for_the_deployments == Tuesday == * CirrusSearch will be enabled on Wikidata as the secondary/non-default search engine. https://www.mediawiki.org/wiki/Extension:CirrusSearch https://www.mediawiki.org/wiki/Search#Timeline == Thursday == * MediaWiki 1.23wmf1 to all Wikipedias * MediaWiki 1.23wmf2 to all testwikis https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap#Schedule_for_the_deployments As always, please let me know if you have any questions. Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
