[Wikitech-l] H.264
http://gigaom.com/2013/10/30/mozilla-will-add-h-264-to-firefox-as-cisco-makes-eleventh-hour-push-for-webrtcs-future/?t=t So, should we support this format now? (not advocating, just curious) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Design] Are external link icons useful
Brion's email reminds me that we sometimes use an icon resembling Adobe's A to identify PDF, which is very ugly for an open standard. FSFE's initiative welcomes design help to make their icons better, their maintainer told me: http://pdfreaders.org/graphics.en.html Also, the Internet Archive brought up a proposal to Create a visual format/style to include an archived link next to an external link. https://www.mediawiki.org/wiki/Archived_Pages Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] H.264
We're churning through some internal discussion with legal on if and how how this affects our potential options... Note that the specific thing announced there doesn't include a licensed AAC *audio* codec which would be required to generate audio and video+audio files playable on current browsers from Apple and Microsoft... so while an interesting development in the codec wars, we don't expect it to immediately change much for us. -- brion On Thu, Oct 31, 2013 at 2:10 AM, Magnus Manske magnusman...@googlemail.comwrote: http://gigaom.com/2013/10/30/mozilla-will-add-h-264-to-firefox-as-cisco-makes-eleventh-hour-push-for-webrtcs-future/?t=t So, should we support this format now? (not advocating, just curious) ___ 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
[Wikitech-l] Fwd: [wikimedia #6138] etherpad.wikimedia.org downtime due to upgrade
FYI, -- Forwarded message -- From: Core operations via RT core-...@rt.wikimedia.org Date: Thu, Oct 31, 2013 at 12:18 PM Subject: [wikimedia #6138] etherpad.wikimedia.org downtime due to upgrade To: akosia...@wikimedia.org Scheduling a downtime for etherpad.wikimedia.org on Wednesday 06/11/2013 in order to upgrade it to the latest released version. The downtime is scheduled to last one (1) hour and will start in 09:00 UTC. We will be upgrading from 1.2.11 (released 3 months ago) to 1.3 (released 10 days ago). Package will be created and will be made available on apt.wikimedia.org during the upgrade. This upgrade will reportedly solve some issues with pad corruption experienced by the Language Engineering team. -- (ticket has been created) -- Alexandros Kosiaris akosia...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] H.264
Maybe you want to read this article: http://xiphmont.livejournal.com/61927.html lbenedix m Do 31.10.2013 10:26, schrieb Brion Vibber: We're churning through some internal discussion with legal on if and how how this affects our potential options... Note that the specific thing announced there doesn't include a licensed AAC *audio* codec which would be required to generate audio and video+audio files playable on current browsers from Apple and Microsoft... so while an interesting development in the codec wars, we don't expect it to immediately change much for us. -- brion On Thu, Oct 31, 2013 at 2:10 AM, Magnus Manske magnusman...@googlemail.comwrote: http://gigaom.com/2013/10/30/mozilla-will-add-h-264-to-firefox-as-cisco-makes-eleventh-hour-push-for-webrtcs-future/?t=t So, should we support this format now? (not advocating, just curious) ___ 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Page title length
This is not an exact answer to your question, but rather a simple and
powerful alternative.
If you are thinking about using Semantic-MediaWiki (which would be
very applicable for a Wiki about resources), you should have a look
at:
http://www.mediawiki.org/wiki/Extension:SemanticTitle
The SemanticTitle extension seems to be currently unmaintained but
just yesterday there has been a talk at SMW-Con here in Berlin which
revealed plans by MITRE to soon commit their recent changes on the
extension and perhaps even maintain it in the future.
More information about the talk:
http://semantic-mediawiki.org/wiki/SMWCon_Fall_2013/Revolutionizing_page_naming_with_semantic_properties
The slides of the talk are already available on that page, a video
recording should follow soon.
Cheers,
Daniel Werner
2013/10/24 Élie Roux elie.r...@telecom-bretagne.eu:
Dear MediaWiki developers,
I'm responsible for the development of a new Wiki that will contain many
Tibetan resources. Traditionnaly, Tibetan titles of books or even parts of
books are extremely long, as you can see for instance here :
http://www.tbrc.org/#!rid=W23922, and sometimes too long for Mediawiki, for
instance the title of
http://www.tbrc.org/?locale=bo#library_work_ViewByOutline-O01DG1049094951|W23922
, which is
ཤངས་པ་བཀའ་བརྒྱུད་ཀྱི་གཞུང་བཀའ་ཕྱི་མ་རྣམས་ཕྱོགས་གཅིག་ཏུ་བསྒྲིལ་བའི་ཕྱག་ལེན་བདེ་ཆེན་སྙེ་མའི་ཆུན་པོ་
. This title is around 90 Tibetan characters, but each caracter being 3
bytes, it exceeds the limit for title length of 256 bytes that MediaWiki
has.
So I have two questions:
1. If I change this limit to 1023 in the structure of the database
('page_title' field of the 'page' base), will other things (such as search
engine) break? Is there a way to change it more cleanly?
2. Could I propose you to make this limit 1023 instead of 255 (or to make it
configurable easily)? This would allow at least 256 characters (even for
asian languages) instead of 256 bytes, which seems more consistant with the
fact that MediaWiki is well internationalized.
Thank you in advance,
--
Elie
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Daniel Werner
Software Engineer
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Wikimedia Bugzilla Guided Bug Entry Form available
Since last Friday, Bugzilla has a guided bug entry form. Together with documentation at https://www.mediawiki.org/wiki/How_to_report_a_bug (which needs an update now) this should make it easier for users to create better bug reports. You can link to and access the guided form by attaching ?format=guided to the enter_bug.cgi URL, like e.g. https://bugzilla.wikimedia.org/enter_bug.cgi?product=Wikimediacomponent=Bugzillaformat=guided If you don't pass product/component parameters in the URL link to https://bugzilla.wikimedia.org/enter_bug.cgi?format=guided the first page (where a bug reporter has to choose a product) still looks the same as usual. I would like to thank the WMF design team and community liaisons for reviews and early feedback. Happy bug reporting, 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] RFC: Refactoring the Title object
Am 30.10.2013 18:32, schrieb Martijn Hoekstra: Rebase early, rebase often. At some point integration must take place. Not using a separate branch won't help you there. Anyone working on anything involving the title object that hasn't been merged yet will hate to rebase whenever you'll have merged back to master though. Which kind of solidifies your original point I disagree - introducing the new features/logic in small increments is more likely to expose any issues early on, and will make it a lot easier to avoid stale patches. The idea is to *not* actually refactor the Title class, but to introduce a light weight alternative, TitleValue. We can then replace usage of Title with usage of TitleObject bit by bit. -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] H.264
Le 31/10/13 10:10, Magnus Manske a écrit : http://gigaom.com/2013/10/30/mozilla-will-add-h-264-to-firefox-as-cisco-makes-eleventh-hour-push-for-webrtcs-future/?t=t So, should we support this format now? (not advocating, just curious) Can we get a summary? -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] H.264
On Thu, Oct 31, 2013 at 9:57 AM, Antoine Musso hashar+...@free.fr wrote: Le 31/10/13 10:10, Magnus Manske a écrit : http://gigaom.com/2013/10/30/mozilla-will-add-h-264-to-firefox-as-cisco-makes-eleventh-hour-push-for-webrtcs-future/?t=t So, should we support this format now? (not advocating, just curious) Can we get a summary? Summarizing http://xiphmont.livejournal.com/61927.html: It seems that there's a yearly cap on the licensing fees for H.264. So Cisco is paying the cap, and then anyone can download binaries implementing the codec from them for free. But there's no redistribution allowed, and of course you have to use some binary library, so presumably Firefox would ask to download the H.264 codec much like it does if you're missing the Flash plugin and go to a page that uses Flash. All in all, ugh. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ 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
Am 31.10.2013 14:52, schrieb Daniel Kinzler: The idea is to *not* actually refactor the Title class, but to introduce a light weight alternative, TitleValue. We can then replace usage of Title with usage of TitleObject bit by bit. That was meant to be replace Title with TitleValue, of course. -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: Deployment postmortem
Everyone, I apologize for the bug. I'll look for ways to guard better against this risk in the future, which will be important as we look to expand coverage of Wikipedia Zero to sister projects and the desktop form factor. Thanks to everyone for resolving the issue so quickly. You guys rule. And Roan, thanks for not flipping over my desk, despite the bug making RL go haywire on Wikidata AND holding up your lightning deployment. It's true - you are a gentleman and a scholar. -Adam On Wed, Oct 30, 2013 at 5:57 PM, Yuri Astrakhan yastrak...@wikimedia.orgwrote: == 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 ___ 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] H.264
quote name=Brad Jorsch (Anomie) date=2013-10-31 time=10:04:56 -0400 On Thu, Oct 31, 2013 at 9:57 AM, Antoine Musso hashar+...@free.fr wrote: Le 31/10/13 10:10, Magnus Manske a écrit : http://gigaom.com/2013/10/30/mozilla-will-add-h-264-to-firefox-as-cisco-makes-eleventh-hour-push-for-webrtcs-future/?t=t So, should we support this format now? (not advocating, just curious) Can we get a summary? Summarizing http://xiphmont.livejournal.com/61927.html: It seems that there's a yearly cap on the licensing fees for H.264. So Cisco is paying the cap, and then anyone can download binaries implementing the codec from them for free. Also good reading on the topic, from one of the main authors of Opus (the best audio codec available, and it happens to be big F Free) and long time Wikipedian Greg Maxwell: http://lwn.net/SubscriberLink/571978/3226db9ce394bf07/ (LWN Subscriber link, join if you like good reporting in this area) Codec licensing amounts to a billion-dollar tax on communication software. In addition, it is used as a weapon between battling competitors, so it even affects people in countries without software patents. quoth Greg. Other Greg. -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikimediaMobile] Fwd: Deployment postmortem
With all my prep work completed ahead of time; I can get a CentralNotice LD out to both production branches in about 15 minutes (waiting on the Jenkins merge is the longest bit of that.) I watch both the fatal and exception logs whilst doing it and then quickly run through the patches to make sure it's all working. I've felt pressured in the LD to get stuff out and myself out of the way when there have been more than two people in it -- which does correlate with my 15 minute estimate for the fastest I feel I can safely deploy. ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Thu, Oct 31, 2013 at 7:53 AM, Adam Baso ab...@wikimedia.org wrote: Everyone, I apologize for the bug. I'll look for ways to guard better against this risk in the future, which will be important as we look to expand coverage of Wikipedia Zero to sister projects and the desktop form factor. Thanks to everyone for resolving the issue so quickly. You guys rule. And Roan, thanks for not flipping over my desk, despite the bug making RL go haywire on Wikidata AND holding up your lightning deployment. It's true - you are a gentleman and a scholar. -Adam On Wed, Oct 30, 2013 at 5:57 PM, Yuri Astrakhan yastrak...@wikimedia.orgwrote: == 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Mobile-l mailing list mobil...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikimediaMobile] Fwd: Deployment postmortem
quote name=Matthew Walker date=2013-10-31 time=10:08:05 -0700 I've felt pressured in the LD to get stuff out and myself out of the way when there have been more than two people in it -- which does correlate with my 15 minute estimate for the fastest I feel I can safely deploy. Thanks for that perspective, Matt. I think that is a reasonable cut off (15 minutes per LD participant, thus 2 per LD window) that will still allow people to use the LDs but also keep our sanity (and site) safe. edited LD page: https://wikitech.wikimedia.org/wiki/Lightning_deployments Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Architecture Summit: participants confirmed
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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] Deployment postmortem
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 tneg...@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 g...@wikimedia.orgwrote: 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 GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Engineering mailing list engineer...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/engineering ___ Engineering mailing list engineer...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/engineering ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: Deployment postmortem
On Thu, Oct 31, 2013 at 1:57 AM, Yuri Astrakhan yastrak...@wikimedia.orgwrote: == 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. Yuri, Thanks for the detailed writeup and for monitoring / quickly resolving the problem. Cheers, Katie == 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- @wikimediadc / @wikidata ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] [WikimediaMobile] Fwd: Deployment postmortem
On Thu, Oct 31, 2013 at 2:48 PM, Max Semenik mseme...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] FOSS OPW status update
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_projects 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Secure and split
Happy Tim Starling Day! :-) It seems this year is the tenth anniversary: https://en.wikipedia.org/wiki/Wikipedia:Tim_Starling_Day. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Secure and split
Except it was yesterday in Oz, right? Happy Tim Day, Mr. Starling...and belated congrats on that second daughter too! 3 D On Oct 31, 2013, at 2:52 PM, MZMcBride z...@mzmcbride.com wrote: Happy Tim Starling Day! :-) It seems this year is the tenth anniversary: https://en.wikipedia.org/wiki/Wikipedia:Tim_Starling_Day. MZMcBride ___ 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] Secure and split
On Fri, Nov 1, 2013 at 7:56 AM, Danese Cooper dan...@gmail.com wrote: Except it was yesterday in Oz, right? Yes Happy Tim Day, Mr. Starling...and belated congrats on that second daughter too! 3 D ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Secure and split
K. Peachey wrote: On Fri, Nov 1, 2013 at 7:56 AM, Danese Cooper dan...@gmail.com wrote: Except it was yesterday in Oz, right? Yes Every holiday is about 48 hours on the Internet. Or something. ;-) As it's still Tim Day here, I just wanted to add that I'm grateful for the work Tim did this past year implementing Scribunto/Lua as a replacement for ParserFunctions. We've already seen impressive parse time improvements from the change. In addition, related editor niceties have been implemented such as CodeEditor (thanks, Brion!) and TemplateSandbox (thanks, Brad!). These extensions enhance the user experience for readers and editors daily. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Secure and split
Hear, hear! There's a cake in the office, hopefully someone can upload him a piece. :D -- brion On Thu, Oct 31, 2013 at 2:52 PM, MZMcBride z...@mzmcbride.com wrote: Happy Tim Starling Day! :-) It seems this year is the tenth anniversary: https://en.wikipedia.org/wiki/Wikipedia:Tim_Starling_Day. MZMcBride ___ 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
[Wikitech-l] Algorithm for assessing quality of articles
I haven't read the paper itself, but just in case someone has a moment and is interested: http://www.technologyreview.com/view/520946/can-automated-editorial-tools-help-wikipedias-declining-volunteer-workforce/ -- Juliusz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Secure and split
Yay! I've been waiting for this day and almost forgot about it. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science On Thu, Oct 31, 2013 at 6:25 PM, Brion Vibber bvib...@wikimedia.org wrote: Hear, hear! There's a cake in the office, hopefully someone can upload him a piece. :D -- brion On Thu, Oct 31, 2013 at 2:52 PM, MZMcBride z...@mzmcbride.com wrote: Happy Tim Starling Day! :-) It seems this year is the tenth anniversary: https://en.wikipedia.org/wiki/Wikipedia:Tim_Starling_Day. MZMcBride ___ 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
