Wikitech-l October 2013

wikitech-l@lists.wikimedia.org

148 participants
152 discussions

Architecture Summit: participants confirmed
by Quim Gil 08 Nov '13

08 Nov '13

Hi, https://www.mediawiki.org/wiki/Architecture_Summit_2014#Participants has been updated in order to reflect the current list of participants confirmed. We are in touch with a few contributors from areas currently underrepresented, and it is possible that some people are still added to the list. Volunteer contributors requiring sponsorship will be contacted via email. The Wikimedia Foundation will cover their flights and accommodation. Please email me if you don't hear from us this week. Wikimedia Foundation employees not based in San Francisco must contact their managers for travel arrangements. The first MediaWiki Architecture Summit 2014 is looking great at least in terms of participation. Next: content. Now it's time to focus in the discussions prior to the event, and the schedule. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

2 2

Optimizing the deployment train schedule
by Erik Moeller 08 Nov '13

08 Nov '13

Hi folks, after speaking to a few folks, I'd like to check in on the WMF deployment train schedule overall, and see if there are ways to optimize it. (Note: In the below I refer to "test wikis" vs. "production wikis", generously including mediawiki.org as a test wiki. I realize that our "test wikis", with the exception of Labs wikis, run on the production cluster.) == Current practice == * On Thursdays we increase the release counter, and deploy the latest release to test wikis and the previous one to Wikipedias. * On Mondays we deploy the latest release to non-Wikipedias. == Problems with this approach == * We only have bits of Thursday and all of Friday to resolve issues that are surfaced in the test wikis prior to the Monday rollout to the first production wikis. * Having two stages of release also increases the cognitive load on developers in understanding when their code hits production wikis, which arguably increases the risk of negative impact of a deploy going unnoticed. == Advantages of this approach == * Commons serves just about enough traffic to sometimes act as a useful canary for performance/scaling issues that will later appear in production. * Developers have some post-deployment time to fix issues highly specific to the non-Wikipedia wikis (e.g. extensions & gadgets only deployed there) rather than being distracted by firefighting on Wikipedia == Some options == Option A: Change nothing. I've not heard from enough folks to see if the problems above are widely perceived to _be_ problems. If the consensus is that current practice, for now, is the best possible approach, obviously we should stick with it. Option B: No Monday deploy. This would mean we'd have to improve our testing process to catch issues affecting the non-Wikipedia wikis before they hit production. I personally think getting rid of the Monday deploy could create some _desirable_ pain that would act as a forcing function to improve pre-release test practices, rather than using production wikis to test. At the same time, we'd have a full week to work out the kinks we find in testing before they hit any production wiki, and could have a more systematic process of backing out changes if needed prior to deployment. Option C: Shift Monday deploys to Tuesday. This would at least give us an additional work day to fix issues that have occurred in testing before they hit prod. I personally don't think this goes far enough, but might be a useful tweak to make if option B seems too problematic. Are there other ways to optimize / issues I'm missing or misrepresenting above? Thanks, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

13 20

Possible topics for the next RFC review
by Rob Lanphier 05 Nov '13

05 Nov '13

Hi folks, Here's the RFCs that have the most interest expressed on the Architecture Summit invite page[1]: https://www.mediawiki.org/wiki/Requests_for_comment/TitleValue https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database https://www.mediawiki.org/wiki/Requests_for_comment/Deprecating_inline_styl… https://www.mediawiki.org/wiki/Requests_for_comment/Password_requirements It's conceivable that Tim and/or Brion could hold an IRC meeting next week, if there's sufficient interest in doing so and they get a little help organizing it. There's perhaps a little pre-meeting setup, some notetaking, and post-meeting wiki gnoming to do. You can check out the meeting from September 24[2] to get an idea of what's needed. Also, there's now a meeting hub[3] for these meetings so that you can see what's coming up and dig up notes from previous meetings a little easier. The more we can get done online prior to the meeting, the more useful our in-person meeting will be in January. Unless we get everything done before the meeting and have nothing to do. I somehow don't think that'll be a problem. :-) Rob [1] https://www.mediawiki.org/wiki/Architecture_Summit_2014 [2] https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2013-09-24 [3] https://www.mediawiki.org/wiki/Architecture_meetings

5 5

Re: [Wikitech-l] [Design] Are external link icons useful
by Jon Robson 03 Nov '13

03 Nov '13

+ wikitech On Tue, Oct 29, 2013 at 8:54 AM, Siebrand Mazeland (WMF) < smazeland(a)wikimedia.org> wrote: > Also see https://gerrit.wikimedia.org/r/#/c/23424/ > > In my opinion, external link icons add a lot of visual noise and not that > much relevant information. > > > On Mon, Oct 28, 2013 at 11:22 PM, Jon Robson <jrobson(a)wikimedia.org>wrote: > >> Changed subject to reflect this change in topic. Also cc'ing design >> mailing list. >> >> In terms of external links to me I don't care about whether I'm leaving >> the site or not. If I clicked on something and it wasn't what I expected >> that's a badly labeled link. A link saying there is more information on the >> [white house official website] and a link to the word [house] should be >> enough information to tell which I'd external and which isn't. >> >> I actually think the only place an icon next to a link really makes sense >> is for downloads. Clicking something that downloads a PDF when I thought it >> was a web page is a little confusing (on mobile at least). >> >> That said if all the external links are in the external links / >> references section wouldn't encouraging that organisation of links be >> better....? >> >> Also I agree with Juliusz that we shouldn't force behaviour of where >> links open. It should be up to the user if they want the same tab or new >> one and it should be configurable within the browser preferences. >> On 24 Oct 2013 16:07, "Juliusz Gonera" <jgonera(a)wikimedia.org> wrote: >> >>> No, we should definitely not warn people, that's just weird ;) It's >>> not like something bad is about to happen. >>> I'm also not saying that users have the expectation that links point to >>> local URLs, I'm only saying that it might be a useful piece of information >>> to some. >>> >>> >>> On 10/24/2013 02:48 PM, Jared Zimmerman wrote: >>> >>> Its definitely a less heavy handed way of doing the thing many >>> (annoying) sites do when they warn you that you're leaving their site. I >>> just wonder is the signal to noise it worth it. I don't know that modern >>> web users have any expectations that link within a site always point to >>> local site urls. >>> >>> * >>> * >>> * >>> * >>> *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia >>> Foundation >>> M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman> >>> >>> >>> >>> >> _______________________________________________ >> Design mailing list >> Design(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/design >> >> > > > -- > Siebrand Mazeland > Product Manager Language Engineering > Wikimedia Foundation > > M: +31 6 50 69 1239 > Skype: siebrand > > Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate > > _______________________________________________ > Design mailing list > Design(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/design > > -- Jon Robson http://jonrobson.me.uk @rakugojon

2 1

H.264
by Magnus Manske 02 Nov '13

02 Nov '13

http://gigaom.com/2013/10/30/mozilla-will-add-h-264-to-firefox-as-cisco-mak… So, should we support this format now? (not advocating, just curious)

8 11

Secure and split
by MZMcBride 31 Oct '13

31 Oct '13

Happy Tim Starling Day! :-) It seems this year is the tenth anniversary: <https://en.wikipedia.org/wiki/Wikipedia:Tim_Starling_Day>. MZMcBride

5 5

FOSS OPW status update
by Quim Gil 31 Oct '13

31 Oct '13

Hi, we are still late but catching up at FOSS Outreach Program for Women: https://www.mediawiki.org/wiki/Outreach_Program_for_Women/Round_7 We have several project ideas listed, most of them coming from Wikimedia Foundation teams. We are still counting on more proposals, from the Flow, Mobile, Labs, and Language teams. Thank you very much! We still encourage other potential mentors (especially non-WMF) to push proposals from https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Raw_pr… We have 10 candidates listed at the wiki page. 9 applicants are from India and 1 from Brazil, which shows that more geographical diversity would be welcome. They are at the early stages of their proposals, but at this point this is mostly our (my) fault for starting late. Anyway, nothing that can't be fixed in the following days. The deadline for applications is November 11. Your help promoting this program in your circles is very important! -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

Re: [Wikitech-l] [Engineering] [WikimediaMobile] Fwd: Deployment postmortem
by Brad Jorsch (Anomie) 31 Oct '13

31 Oct '13

On Thu, Oct 31, 2013 at 2:48 PM, Max Semenik <msemenik(a)wikimedia.org> wrote: > > 1) Move them at least 1 hour earlier so that we never end in the situation > when someone deploys a change and goes home. With people in all different timezones, I don't think "never having someone deploy then go home" is going to be possible. For myself, for example, even if we move the LD an hour earlier I'll still normally have been "home" for an hour before LD starts. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation

1 0

Fwd: Deployment postmortem
by Yuri Astrakhan 31 Oct '13

31 Oct '13

== Background == ZeroRatedMobileAccess has always depended on MobileFrontend and used it liberally, including calls to its classes. However, it was done in hooks called by MF so Zero simply stopped working in absence of MF. This, however, changed in [1] where Zero started using a ResourceLoader module from MF. == What happened == At 23:02pm UTC, after deploying Zero extension updates, fatal monitor was flooded with: -- Fatal error: Class 'MFResourceLoaderModule' not found in /usr/local/ apache/common-local/php-1.23wmf1/includes/resourceloader/ResourceLoader.phpon line 408 The issue was tracked down to Wikidata having MobileFrontend disabled, while ZeroRatedMobileAccess was enabled. It didn't impact page views directly, however all load.php calls that requested the startup module caused fatals because it attempted to instantiate MFResourceLoader class and couldn't find it. As a consequence, people might have seen pages without styles or scripts. A number of people (MaxSem, Reedy, Roan, and Greg, and possibly others) gave great assistance to track down the issue and rapidly disable the ZeroRatedMobileAccess extension in Wikidata. Furthermore, mobile configuration [2] will add an additional guard against calling ZeroRatedMobileAccess.php unless it's explicitly within the context of MF. Thank you to everyone!!! == Timeline == All times in UTC * 22:48 Zero 1.22wmf22 deployed, no errors * 23:02 Zero 1.23wmf1 deployed, first errors appear - initially unnoticed * 23:08 A small MobileFrontend change deployed * 23:09 Errors noticed, initially linked with MobileFrontend push * 23:17 Max reverts his MobileFrontend changes, errors don't go away * 23:22 Problem narrowed down * 23:27 Fix deployed == Recomendations == * Allow a bit more time between deployments and observe fatalmonitor before and after * Ensure Zero extension checks if Mobile extension is loaded before enabling itself if it relies on MFResourceLoader. ------ [1] https://gerrit.wikimedia.org/r/#/c/83133 [2] https://gerrit.wikimedia.org/r/#/c/92811

5 4

Re: [Wikitech-l] [Engineering] Deployment postmortem
by Chris McMahon 31 Oct '13

31 Oct '13

One thing that impressed me when I started working with WMF is that reverting in production is as safe as I have ever seen any production environment. In the 20 months or so I've been here, I think I only remember one change that left behind corrupt data in prod, and that change was made by a volunteer, the bug was manifested in beta labs but we failed to recognize the importance of the bug, and then the change to the code was merged on Thanksgiving Day by someone not on the team affected by the change-- one of those perfect storm sort of problems. We're good at reverting. On Thu, Oct 31, 2013 at 12:26 PM, Toby Negrin <tnegrin(a)wikimedia.org> wrote: > How easy is it to rollback production changes? Is this something that can > be consistently done easily with our current tools. At other high traffic > sites I've worked at this has been an important component of production > engineering. > > -Toby > > > On Wed, Oct 30, 2013 at 6:12 PM, Greg Grossmeier <greg(a)wikimedia.org>wrote: > >> First: Thanks for responding to this and writing it up. >> >> <quote name="Yuri Astrakhan" date="2013-10-31" time="04:53:44 +0400"> >> > == Recomendations == >> > * Allow a bit more time between deployments and observe fatalmonitor >> before >> > and after >> >> Agreed. >> >> I put a ton of blame on myself for not slowing down the cadence of LD >> slots when a bunch of people are trying to get in on the same day. >> >> For future LDs I am going to explicitly ask everyone to do what Yuri >> suggests (monitor fatals after your deploy) before saying that you're >> done. 5 minutes post-deploy of watching the fatalmonitor isn't >> unreasonable, I don't think. >> >> Relatedly, I think we should reassess the Lightning Deploys :) >> >> Not necessarily to get rid of them (probably not), but: >> 1) how many deploys can go in one LD? How many do we *want* to go? >> >> 2) from 1, is the length of the LD long enough/too long? >> >> 3) LD management is still pretty high-communication ("Alright, who's in >> line? Who's up next? Are you done yet?") There are basic tools that can >> help with this (Etsy has an IRC "pushbot" that manages the queue mostly >> automatically, for instance); I'll look into those/test them. >> >> 4) probably more, aka: your thoughts? >> >> >> Greg >> >> PS: graph of the fatals attached, just for completenesses sake. >> >> -- >> | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | >> | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D | >> >> _______________________________________________ >> Engineering mailing list >> Engineering(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/engineering >> >> > > _______________________________________________ > Engineering mailing list > Engineering(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/engineering > >

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l October 2013