If you are interested in the productivity and success of the Wikimedia
Developer Summit 2016, please check this workboard with all the session
proposals:
https://phabricator.wikimedia.org/tag/wikimedia-developer-summit-2016/?orde…
Currently there are 20 proposals "Missing expected fields". This means that
they lack a clear plan for the Summit (what are you planning to do with a
slot in the schedule) and/or topics to be discussed online between now and
the event.
There are 10 proposals "Missing active discussion". This means that the
proposal is formally correct, but it doesn't seem to be attracting a
critical mass of interest right now.
You can help putting the proposals you find interesting On Track. You can
help improving descriptions, associating relevant projects, subscribing
people that should be aware, and contributing to discussions. Your online
contributions today (and your silence) are defining the Summit schedule,
and also how productive the scheduled sessions will be at the end.
Thank you for everybody involved so far! The difference of preparation
between this Summit and its predecessors is promising. Keep it going, and
the rest please don't wait and get involved.
PS: next deadline, November 6
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016#Submissions_…
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2015.10. This bundle is compatible with MediaWiki 1.24.x and
MediaWiki 1.25.x releases.
Next MLEB is expected to be released in 3 months. We are trying less
frequent releases due to low number of changes per month in the
included extensions. If there are major changes or important bug
fixes, we will do intermediate release. Please give us your feedback
at [[Talk:MLEB|https://www.mediawiki.org/wiki/Talk:MLEB]].
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2015.10.tar…
* sha256sum: 482595d35ab02fdc40c6ae54d2cf21aa22360f7021d498c054624ccdbf721237
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://phabricator.wikimedia.org/
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Babel ==
* Extension is no longer automatically loaded when installed via composer.
* Support for extension registration was added.
* Configuration options for CDB file locations were removed.
== CleanChanges and LocalisationUpdate ==
* Localisation updates only.
== CLDR ==
* Extension is no longer automatically loaded when installed via composer.
* Updated to CLDR 28.
== Translate ==
* MediaWiki 1.23 is no longer supported. Extension is no longer
automatically loaded when installed via composer.
* If local TTMServer translation memory is marked as public, it will
not automatically take advantage of TranslationWebServices query
parallelization.
* Allows a user to easily access search operators with autocompletion
on Special:SearchTranslations.
* Language and group selectors now interact better on Special:Translate
* Results are always shown when searching for a full page title on
Special:SearchTranslations for a known message.
* Special:Translate now says explicitly that it needs JavaScript to function.
* TranslationWebServices now display correct error message for query
failures in the logs.
* Minor display fix on Special:Translate page mode that was caused by
rounding errors.
* TTMServer translation memory can be used with wikimedia extra
elasticsearch plugin version 1.7.1 to avoid enabling scripting in
ElasticSearch.
* Flash of unstyle content no longer happens or is reduced on
translatable pages, on Special:SearchTranslations and on
Special:Translate.
* $wgTranslateSupportUrl can now contain a full URL ('url' key).
$wgTranslateSupportUrlNamespace is added to override the general
configuration for specific namespaces.
== UniversalLanguageSelector ==
* MediaWiki 1.23 is no longer supported. Extension is no longer
automatically loaded when installed via composer.
* Language change is now done in two phase: first changed with API,
then page is reloaded. The 'setlang' URL parameter is no longer used,
although it still works. Due to the change, language switching might
take a slightly longer than previously.
* Previous language selection is now stored in localstorage instead of cookies.
* Support added for Livvi-Karelian (olo) language.
* Input Methods:
** Various fixes in bo-ewts (Tibetan EWTS) keyboard layout.
** Fixed name of gu-transliteration (Gujarati Transliteration) input method.
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com
In a recent blog post ( http://esr.ibiblio.org/?p=6867 ) ESR writes:
High on my list of Things That Annoy Me When I Hack is sourcefiles that
> contain huge blobs of license text at the top. That is valuable territory
> which should be occupied by a header comment explaining the code, not a
> boatload of boilerplate that I’ve seen hundreds of times before.
...and then goes on to explain using SPDX identifiers to refer to licenses,
which would look something like this:
/* Copyright 2015 by XYZ
* SPDX-License-Identifier: GPL-2.0+
*/
Any objections to making that the new standard / replacing existing blocks
with this? It would make the PHP files a little more readable.
I would appreciate some discussion and feedback on a change that I have
proposed to MediaWiki core [0,1].
The DISPLAYTITLE magic word allows alternate text to be displayed for the
title of a page [2]. The SemanticTitle extension builds upon this
capability enabling alternate mechanisms to set the display title [3]. The
display title functionality in MediaWiki core is currently implemented
using the page_props table [4]. I recently proposed a MediaWiki core change
to a) encapsulate access to the page_props table in a class and b) extend
the usage of a page’s displaytitle property so that it is also used as the
link text for links to the page. That latter point is functionality
currently in the SemanticTitle extension that would be re-implemented in
core and removed from SemanticTitle. Two questions regarding the proposed
patch were raised about which I would appreciate additional discussion.
The first question is whether the display title functionality should be
re-implemented as a part of the Article or WikiPage class. I support that
suggestion, but before pursuing that path would like additional input,
because it would require a larger change to core, including a database
modification. One of the advantages of this approach would be that the
display title could be updated in the database immediately when a page is
saved; in the current approach, the update to the page_props table is
deferred, causing a lag between when the user makes the change and when
links relying upon this information would be updated accordingly.
The second question is whether querying for the display title while
creating page links would impose a performance penalty. While we have not
seen a penalty in our environment, perhaps there are environments in which
this would have a greater cost. Would this cost be significant? It is
possible that changing the implementation to being part of the Article or
WikiPage class could alleviate some of this penalty, since the display
title information could be retrieved when other information for the page is
accessed from the database.
I would appreciate additional input on these changes to help decide upon
next steps. Thank you!
Cindy (https://www.mediawiki.org/wiki/User:Cindy.cicalese)
[0] https://phabricator.wikimedia.org/T115331
[1] https://gerrit.wikimedia.org/r/#/c/246246/
[2] https://www.mediawiki.org/wiki/Manual:$wgAllowDisplayTitle
[3] https://www.mediawiki.org/wiki/Extension:Semantic_Title
[4] https://www.mediawiki.org/wiki/Manual:Page_props_table
Hi everyone,
Thanks to Gergo for bringing up this issue. Everyone has raised good
points and I just want to link to existing guidance from the Software
Freedom Law Center
<https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html>
on
best practices for developers to address the problem of long license and
copyright headers by linking to external files. As noted in the guidance
document, by referencing the appropriate information files located in a
centralized location, not only do we reduce clutter in the header but we
also increase maintainability of license and copyright info.
Therefore for the header, as an example, we could have something like this:
>
> This file is part of the MediaWiki Project. Copyright 2015 The MediaWiki
> Project Developers.
>
> For full copyright information and for the licensing terms governing the
> project and all its files, see the COPYING file at the top-level directory
> of this distribution and at
> https://github.com/wikimedia/mediawiki/blob/master/COPYING.
where in turn the COPYING file could contain references to the updated list
of authors, a description of the project, and the licensing information.
As to the specifics of SPDX use for all our projects and licenses, we will
have to do a little more research on this. Happy to talk off-thread about
this as well.
Thanks,
Zhou
> From: Tyler Romeo <tylerromeo(a)gmail.com>
> Date: Tue, Oct 27, 2015 at 12:03 PM
> Subject: Re: [Wikitech-l] Short license blocks
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
>
>
> The Apache license, which is also permissive, has a similar recommended
> file header.
>
> I'd say we just standardize on having the warranty disclaimer and license
> notice in every file. It's an easy approach to make sure somebody reading
> the file can easily tell the license without having to maintain
> comprehensive authorship information in every file.
> On Oct 27, 2015 14:17, "Ryan Kaldari" <rkaldari(a)wikimedia.org> wrote:
>
> > I was saying that we could go ahead and make this the standard for
> non-GPL
> > MediaWiki code (basically, the few MIT licensed extensions). I'm not sure
> > if the advantage of doing that would outweigh the disadvantage of having
> a
> > non-standard standard though.
> >
> > On Tue, Oct 27, 2015 at 11:06 AM, Tyler Romeo <tylerromeo(a)gmail.com>
> > wrote:
> >
> > > Are you saying adopting the short license blocks? Or the MIT license?
> > > Because I'm not sure how the licenses of extensions would affect the
> > > license headers in core.
> > > On Oct 27, 2015 12:43, "Ryan Kaldari" <rkaldari(a)wikimedia.org> wrote:
> > >
> > > > <flamebait>
> > > > I totally support switching to license identifiers instead of
> headers,
> > > > provided that we also switch our licensing from GPL to MIT or BSD ;)
> > > > </flamebait>
> > > >
> > > > On a serious note, we do have a fair number of extensions that are
> MIT
> > > > Licensed and could go ahead and adopt this (
> > > > https://www.mediawiki.org/wiki/Category:MIT_licensed_extensions).
> > > >
> > > >
> > > > On Tue, Oct 27, 2015 at 3:44 AM, Gergo Tisza <gtisza(a)wikimedia.org>
> > > wrote:
> > > >
> > > > > In a recent blog post ( http://esr.ibiblio.org/?p=6867 ) ESR
> writes:
> > > > >
> > > > > High on my list of Things That Annoy Me When I Hack is sourcefiles
> > that
> > > > > > contain huge blobs of license text at the top. That is valuable
> > > > territory
> > > > > > which should be occupied by a header comment explaining the code,
> > > not a
> > > > > > boatload of boilerplate that I’ve seen hundreds of times before.
> > > > >
> > > > >
> > > > > ...and then goes on to explain using SPDX identifiers to refer to
> > > > licenses,
> > > > > which would look something like this:
> > > > >
> > > > > /* Copyright 2015 by XYZ
> > > > > * SPDX-License-Identifier: GPL-2.0+
> > > > > */
> > > > >
> > > > > Any objections to making that the new standard / replacing existing
> > > > blocks
> > > > > with this? It would make the PHP files a little more readable.
> > > > > _______________________________________________
> > > > > Wikitech-l mailing list
> > > > > Wikitech-l(a)lists.wikimedia.org
> > > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > > _______________________________________________
> > > > Wikitech-l mailing list
> > > > Wikitech-l(a)lists.wikimedia.org
> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > _______________________________________________
> > > Wikitech-l mailing list
> > > Wikitech-l(a)lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
--
Zhou Zhou
Legal Counsel
Wikimedia Foundation
149 New Montgomery Street, 6th Floor
San Francisco, CA 94105
zzhou(a)wikimedia.org
NOTICE: This message might have confidential or legally privileged
information in it. If you have received this message by accident, please
delete it and let us know about the mistake. As an attorney for the
Wikimedia Foundation, for legal/ethical reasons I cannot give legal advice
to, or serve as a lawyer for, community members, volunteers, or staff
members in their personal capacity. For more on what this means, please see
our legal disclaimer
<https://meta.wikimedia.org/wiki/Wikimedia_Legal_Disclaimer>.
All Wikimedia sites show me the same error. I'd log a bug if I could login:
MediaWiki internal error.
Exception caught inside exception handler.
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php
to show detailed debugging information.
Regards,
Strainu
Please join for the following tech talk:
*Tech Talk**:* Introduction to Free and Open Source Licensing at Wikimedia
*Presenter:* Stephen LaPorte
*Date:* October 23, 2015
*Time: *17:00 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Tech+Talk%3A+Intro…>
-
17:30 UTC
Link to live YouTube stream <http://www.youtube.com/watch?v=sWiDimlK4bE>
*IRC channel for questions/discussion:* #wikimedia-office
Google+ page
<https://plus.google.com/u/0/b/103470172168784626509/events/caldda1kv3bnde8d…>,
another
place for questions
*Summary: *The Wikimedia Foundation maintains and contributes to some
significant free and opens source projects. This talk will discuss free and
open source licensing best practices and why it's important for Wikimedia.
We'll review different types of licenses, common terms, and how to use
them. This talk will be introductory, and there will be an opportunity for
questions and discussion.
---------- Forwarded message ----------
From: Kevin Leduc <kevin(a)wikimedia.org>
Date: Thu, Oct 15, 2015 at 6:47 PM
Subject: October Lightning Talks
To: "Staff (All)" <wmfall(a)lists.wikimedia.org>, Engineering list <
engineering(a)lists.wikimedia.org>
Hello!
October's Lightning Talks are in less than 2 weeks and we are looking for
more volunteers to present. Lightning Talks are an opportunity for teams @
WMF & in the Community to showcase a Quarterly Goal achieved, significant
milestone, release, or anything of significance to the rest of the
foundation and the movement as a whole. This month we will also have some
Google Summer of Code participants showcase their work on Mediawiki.
Each presentation will be 10 minutes or less, the formal part should be not
be longer than 5 minutes and the remainder can be used for questions.
Too many questions to answer in the allotted time? No worries, your
lightning talk will be a great candidate for a future Tech Talk.
Next round of Lightning Talks:
When: Tuesday October 27, 1800 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Lightning+Talks&is…>,
11am PDT
Where: 5th Floor
Remotees: On-Air google hangout will be provided just before the meeting
IRC: #wikimedia-tech
Sign up for a 10 minute slot here:
https://www.mediawiki.org/wiki/Lightning_Talks
Thanks!
Kevin Leduc, Rachel Farrand, Megan Neisler
On Oct 27, 2015 7:29 AM, "Risker" <risker.wp(a)gmail.com> wrote:
>
> On 27 October 2015 at 09:57, Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org>
> wrote:
>
> > On Tue, Oct 27, 2015 at 8:02 AM, Risker <risker.wp(a)gmail.com> wrote:
> >
> > > The incident report does not go far enough back into the history of
the
> > > incident. It does not explain how this code managed to get into the
> > > deployment chain with a fatal error in it.
> >
> >
> > Actually, it does. Erik writes "This occured because the patch for the
> > CirrusSearch repository that removed the schema should have been
deployed
> > before the change that adds it to the WikimediaEvents repository."
> >
> > In other words, there was nothing wrong with the code itself. The
problem
> > was that the multiple pieces of the change needed to be done in a
> > particular order during the manual backporting process, but they were
not
> > done in that order.
> >
> > If this had waited for the train deployment, both pieces would have been
> > done simultaneously and it wouldn't have been an issue, just as it
wasn't
> > an issue when these changes were done in master and automatically
deployed
> > to Beta Labs.
> >
> >
> That's a start, Brad. But even as someone who has limited experience with
> software deployment, I can think of at least half a dozen questions that
> I'd be asking here:
>
> - Why wasn't it part of the deployment train
This was a fix for something that broke during the previous deployment
train. Specifically a hook was changed in core and not noticed in the
extenaion until the events from javascript stopped coming into our logging
tables.
> - As a higher level question, what are the thresholds for using a SWAT
> deployment as opposed to the regular deployment train, are these
standards
> being followed, and are they the right standards. (Even I notice that
most
> of the big problems seem to come with deployments outside of the
deployment
> train.)
This is documented at https://wikitech.wikimedia.org/wiki/SWAT_deploys. I'm
not sure about previous outages but in this case the patch matches the
documented limits. My intuition is a that a dep
> - How was the code reviewed and tested before deployment
Code was re
> - Why did it appear to work in some contexts (indicated in your
response
> as master and Beta Labs) but not in the production context
Because, as stated in the report and by brad, the code itself works. The
code was redeployed after the outage with no errors because the second time
it was deployed in the correct order. This is why code review didn't catch
the fatal and the error didn't show up in beta labs. This was an issue
primarily with deployment process.
> - How are we ensuring that deployments that require multiple sequential
> steps are (a) identified and (b) implemented in a way that those steps
are
> followed in the correct order
>
>
> Notice how none of the questions are "what was wrong with the code" or
"who
> screwed up". They're all systems questions. This is a systems problem.
> Even in situations where there *is* a problem with the code or someone
> *did* screw up, the root cause usually comes back to having single points
> of failure (e.g. one person having the ability to [unintentionally] get
> problem code deployed, or weaknesses in the code review and testing
> process).
>
> Risker/Anne
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
At a higher level, this was a 9 minute outage instead of a 2 or 3 minute
outage due to two mistakes I made while doing the revert. Both of these are
in the incident report. First the monitor I was watching from our logserver
to tell me it needs a rollback did not report this error adding a minute or
two before the rollback started. We have other monitors that have been
added in the past year that I should have been looking at as well. Second I
reverted multiple patches from within gerrit (our code review tool) which
takes too long when the site is down. I can only point to inexperience
here, others who have previously taken our sites down informed me that the
proper was is to revert is directly on the deployment server. Iv been
deploying patches and to wmf for a couple years and have always in the past
reverted through gerrit, but those didn't need the extra speedy recovery as
the site was not down, it was only logging errors or some specific piece of
functionality was not working.
Going up another level comes to our deployment tooling specifically. RelEng
is working on a project called scap3 which brings our deployment process
closer to what you should expect from a top 10 website. It includes canary
deployments (eg 1% of servers) along with a single command that undoes the
entire deployment. Canary deployments allow to see an error before it is
deployed everywhere, and a one command rollback operation would have likely
brought the site back 3 to 4 minutes faster than how I reverted the patches.
I did not link the scap3 portions as an actionable because, in my mind,
that's not a single actionable thing. Scap3 is a major overhaul of our
deploy process. Additionally this is already a priority in RelEng.