Re: [Wikitech-l] Fwd: Announcing Patrick Reilly as Site Performance Engineer and Senior Technical Advisor
Congratulations Patrick! Are you now the right person one should ask decisions/updates to for stale performance/platformeng bugs? https://bugzilla.wikimedia.org/buglist.cgi?keywords=performance%2C%20platformengkeywords_type=anywordsresolution=---query_format=advancedlist_id=172284 Or questions such as «which pages are safe to run an update on even on en.wiki, and how frequently; and which would kill it? Or, at what point a wiki is too big to run such updates carelessly?» (http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/65463/ ) https://bugzilla.wikimedia.org/show_bug.cgi?id=15434 Thanks, Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: Announcing Patrick Reilly as Site Performance Engineer and Senior Technical Advisor
Erik wrote: it's my pleasure to announce the promotion of Patrick Reilly to the role of Site Performance Engineer and Senior Technical Advisor. It's been planned for a long time for Patrick to focus on site performance as his next step after his role on the mobile team. On the mobile team, he was responsible for building out the initial MobileFrontend extension, and has been the team's tech lead since then, succeeded in this role by Brion Vibber. I've decided to also designate Patrick as Senior Technical Advisor. Patrick has been invaluable in the last few weeks in supporting hiring processes, cross-team coordination, and technical evaluations. I will continue to rely on Patrick's expertise and network to support technical coordination across the department. This is one of the near term improvements to increase my bandwidth and capacity as well. Patrick will report to me. For performance and architecture projects, he'll work directly with engineers working in those areas (Tim, Asher, Aaron, Ori, etc.). I've posted the job description for this role here for reference: https://wikimediafoundation.org/wiki/Job_openings/Site_Performance_Engineer_and_Senior_Technical_Advisor It's been gratifying in the last few years to see our capacity to improve site performance on an architectural level, and to react immediately to site performance crises, improve substantially. I look forward to yet another step in this direction and I have just added https://www.mediawiki.org/wiki/Site_performance to my watchlist. :-) Patrick, can you talk a little about what your first priorities are in this role? Or how the Wikimedia technical community can help? Right now https://www.mediawiki.org/wiki/Manual:Database_layout/MySQL_Optimization/Tutorial and https://www.mediawiki.org/wiki/Manual:Performance_tuning are the resources helping volunteers see how to write and review code -- more guidance in what people need training in would be welcome. On 01/10/2013 06:51 AM, Federico Leva (Nemo) wrote: Congratulations Patrick! Are you now the right person one should ask decisions/updates to for stale performance/platformeng bugs? https://bugzilla.wikimedia.org/buglist.cgi?keywords=performance%2C%20platformengkeywords_type=anywordsresolution=---query_format=advancedlist_id=172284 Or questions such as «which pages are safe to run an update on even on en.wiki, and how frequently; and which would kill it? Or, at what point a wiki is too big to run such updates carelessly?» (http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/65463/ ) https://bugzilla.wikimedia.org/show_bug.cgi?id=15434 Thanks, Nemo Andre, Nemo has a good question. :-) Basically, who is the product manager for site performance, who can prioritize upcoming work and Bugzilla issues and specify workflows and guidelines as Nemo would like? Can you coordinate with Patrick to figure that out? -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Developers: what are you working on? (or Improving the release notes for 1.21)
On 01/09/2013 10:27 PM, Matthew Flaschen wrote: Tired of all your MediaWiki i18n messages showing on the JavaScript side as wikitext? Parse them with jqueryMsg, now with wikilinks and int: transclusion support! This is awesome. Short blurbs like this would make the release notes much easier to read -- as long as they were backed up with more substantial information. As I work on the release notes page, I'll see if I can't get more of these. -- http://hexmode.com/ Language will always shift from day to day. It is the wind blowing through our mouths. -- http://hexm.de/np ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: Announcing Patrick Reilly as Site Performance Engineer and Senior Technical Advisor
On Thu, 2013-01-10 at 09:25 -0500, Sumana Harihareswara wrote: On 01/10/2013 06:51 AM, Federico Leva (Nemo) wrote: Congratulations Patrick! Are you now the right person one should ask decisions/updates to for stale performance/platformeng bugs? https://bugzilla.wikimedia.org/buglist.cgi?keywords=performance%2C%20platformengkeywords_type=anywordsresolution=---query_format=advancedlist_id=172284 For everybody's info, there are 28 open bug reports (excluding enhancement requests) with the keyword performance. Or questions such as «which pages are safe to run an update on even on en.wiki, and how frequently; and which would kill it? Or, at what point a wiki is too big to run such updates carelessly?» (http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/65463/ ) https://bugzilla.wikimedia.org/show_bug.cgi?id=15434 Andre, Nemo has a good question. :-) Basically, who is the product manager for site performance, who can prioritize upcoming work and Bugzilla issues and specify workflows and guidelines as Nemo would like? Can you coordinate with Patrick to figure that out? In my understanding I wouldn't call performance a product (no identifiable codebase, hence also the Bugzilla *keyword* across products) but I see what you mean. :) I'd also love to see the documentation asked for by Nemo, also as it would help to have a bug report seen by the right developer. Let me try to follow up. 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] How to contribute to sysadmin / devops
On Tue, 2013-01-08 at 11:01 -0800, Ryan Lane wrote: There's a list of Labs infrastructure bugs: https://bugzilla.wikimedia.org/buglist.cgi?list_id=171774resolution=---resolution=LATERresolution=DUPLICATEquery_format=advancedcomponent=Infrastructureproduct=Wikimedia%20Labs I think what we're mostly missing is a quick list of easy things to do or fix as a call to action. In case there are some open Bugzilla tickets that describe easy things to fix, please feel free to set the keyword easy on them, so potential new contributors can query for them. 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] Rewriting ExtensionDistributor
On Tue, Jan 8, 2013 at 7:01 AM, Chad innocentkil...@gmail.com wrote: Why not use what we already use: REL1_20 etc. At the time, I thought it might conflict with something. However, you're probably right and it'll be easier to remember :) I've now tagged all extensions (that existed) when REL1_20 was branched on 2012-11-06 [0]. I'm about to do the same for REL1_19 (more time consuming, since we weren't on git yet). Remember: if you're the owner of any extension and you want to change what's available to ExtensionDistributor, you can just update the REL1_nn tags to point to the commit you want people to use. For future release branches: we should probably add this to the how to do a release instructions[1] (which I've just done...man that page needs a cleanup). -Chad [0] https://www.mediawiki.org/wiki/Branch_points [1] https://www.mediawiki.org/wiki/Release_checklist ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Rewriting ExtensionDistributor
On Thu, Jan 10, 2013 at 10:32 AM, Chad innocentkil...@gmail.com wrote: On Tue, Jan 8, 2013 at 7:01 AM, Chad innocentkil...@gmail.com wrote: Why not use what we already use: REL1_20 etc. At the time, I thought it might conflict with something. However, you're probably right and it'll be easier to remember :) I've now tagged all extensions (that existed) when REL1_20 was branched on 2012-11-06 [0]. I'm about to do the same for REL1_19 (more time consuming, since we weren't on git yet). Remember: if you're the owner of any extension and you want to change what's available to ExtensionDistributor, you can just update the REL1_nn tags to point to the commit you want people to use. For future release branches: we should probably add this to the how to do a release instructions[1] (which I've just done...man that page needs a cleanup). -Chad [0] https://www.mediawiki.org/wiki/Branch_points [1] https://www.mediawiki.org/wiki/Release_checklist And we're now done for REL1_19 too. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Apologies for delayed i18n/L10n review on Gerrit patch sets
Over the past week or so, I've found the review bot[1] created by Merlijn extremely helpful. It automatically adds me as reviewer to all patch sets that make changes to a file with i18n or Messages in the path. I try to review within 12 hours, but as I need to sleep, spend time with the family, eat and work on other stuff also, that sometimes doesn't happen. I'm also subscribed to the mailing list mediawiki-commits, which is a stream for *all* changes that come through Gerrit. Very high volume (200-400 e-mails a day), but very useful for the type of work I do. Hard to keep up with, too. Reviewer bot has malfunctioned a few times over the past few days. In those cases I was not added as a reviewer. Apologies if I failed to review your patch set. If you want to ensure that I have a look at it, please add siebrand to the reviewers of your patch set. Sometimes I'm able to also review patch sets other than i18n/L10n related, but because if a high workload, I sometimes decline requests for review that are outside of my direct scope. I hope you understand. Other users that can review your i18n related patch sets are Amir Aharoni, Niklas Laxström and Santhosh Thottingal. Feel free to send me a mail if you think your patch set should have gotten an i18n review already, but didn't. Rock on! [1] http://www.mediawiki.org/wiki/Git/Reviewers -- Siebrand Mazeland Product Manager Language Engineering Wikimedia Foundation M: +31 6 50 69 1239 Skype: siebrand Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Wikimedia engineering December 2012 report
Hi, The report covering Wikimedia engineering activities in December 2012 is now available. Wiki version: https://www.mediawiki.org/wiki/Wikimedia_engineering_report/2012/December Blog version: https://blog.wikimedia.org/2013/01/10/engineering-december-2012-report/ We're also proposing a shorter, simpler and translatable version of this report that does not assume specialized technical knowledge: https://www.mediawiki.org/wiki/Wikimedia_engineering_report/2012/December/summary Below is the full HTML text of the report, as previously requested. As always, feedback is appreciated about the usefulness of the report and its summary, and on how to improve them. Major news in December include: - The launch of an alpha, opt-in version of the VisualEditorhttps://blog.wikimedia.org/2012/12/12/try-out-the-alpha-version-of-the-visualeditor/to the English Wikipedia, a project more complex than it appearshttps://blog.wikimedia.org/2012/12/07/inventing-as-we-go-building-a-visual-editor-for-mediawiki/ ; - A research studyhttps://blog.wikimedia.org/2012/12/20/article-feedback-new-research-and-next-steps/on the use of the Article Feedback feature; - New metrics for the MediaWiki communityhttps://blog.wikimedia.org/2012/12/10/introducing-mediawiki-community-metrics/ ; - The start of the Outreach Program for Womenhttps://blog.wikimedia.org/2012/12/11/welcome-to-floss-outreach-program-for-women-interns/ ; - Continued work to improve the workflowhttps://blog.wikimedia.org/2012/12/12/translation-interface-makeover-in-progress/and interfacehttps://blog.wikimedia.org/2012/12/31/translation-editor-growing-snazzier/for translators. *Note: We're also proposing a shorter, simpler and translatable version of this reporthttps://www.mediawiki.org/wiki/Wikimedia_engineering_report/2012/December/summarythat does not assume specialized technical knowledge. * Personnel Work with us https://wikimediafoundation.org/wiki/Work_with_us Are you looking to work for Wikimedia? We have a lot of hiring coming up, and we really love talking to active community members about these roles. - Software Engineer - Visual Editorhttp://hire.jobvite.com/Jobvite/Job.aspx?j=otYPWfwW - Software Engineer - Editor Engagementhttp://hire.jobvite.com/Jobvite/Job.aspx?j=ovvXWfwD - Software Engineer (Partners)http://hire.jobvite.com/Jobvite/Job.aspx?j=oX2hWfwW - Software Engineer (Apps)http://hire.jobvite.com/Jobvite/Job.aspx?j=oqU0Wfw0 - Software Developer General (Mobile)http://hire.jobvite.com/Jobvite/Job.aspx?j=o4cKWfwG - Git and Gerrit software development (Contract)http://hire.jobvite.com/Jobvite/Job.aspx?j=o4gIWfwI - Release Manager http://hire.jobvite.com/Jobvite/Job.aspx?j=oZrQWfwW - Software Engineer - Multimediahttp://hire.jobvite.com/Jobvite/Job.aspx?j=oj40Wfw3 - Software Engineer (Search)http://hire.jobvite.com/Jobvite/Job.aspx?j=ogk1Wfwh - Product Manager (Mobile)http://hire.jobvite.com/Jobvite/Job.aspx?j=oGWJWfw1 - Director of User Experiencehttp://hire.jobvite.com/Jobvite/Job.aspx?j=otv0WfwE - Visual Designer http://hire.jobvite.com/Jobvite/Job.aspx?j=oomJWfw9 - Operations Engineerhttp://hire.jobvite.com/Jobvite/Job.aspx?j=ocLCWfwf - Operations Engineer/Database Administratorhttp://hire.jobvite.com/Jobvite/Job.aspx?j=obMOWfwr - Site Reliability Engineerhttp://hire.jobvite.com/Jobvite/Job.aspx?j=o7k2Wfw9 Announcements - Matthew Flaschen joined the Wikimedia Features engineeringhttps://www.mediawiki.org/wiki/Wikimedia_Features_engineeringteam as Features Engineer ( announcementhttp://lists.wikimedia.org/pipermail/wikitech-l/2012-December/064916.html ). - Mike Wang joined the Operations team as part time Labs Ops Engineer (consultant) (announcementhttp://lists.wikimedia.org/pipermail/wikitech-l/2012-December/064768.html ). Technical Operations *Production Site Switchoverhttp://wikitech.wikimedia.org/view/Eqiad_Migration_Planning * The Technical Operations team continued to work on completing the outstanding migration tasks, and to ready our Ashburn infrastructure for the big switchover day, i.e., the complete transition from the Tampa datacenter to the one in Ashburn, on the week of January 22, 2013.In the past few months, we've transitioned services from the Tampa datacenter to the one in Ashburn, which now serves most of our traffic (about 90%). However, application (MediaWiki), memcached and database systems are all still running exclusively out of Tampa. We have been working to upgrade the technologies and set up those systems at Ashburn, and we plan to perform the switchover of those services from Tampa to Ashburn in the coming weeks. This will provide us some assurance of a hot standby datacenter, should we encounter an irrecoverable and lengthy outage in one of the main datacenters. *Site Infrastructure* Because December is when the annual Wikimedia fundraiser
