TLDR: The backend server used for releases.wikimedia.org has moved.
use bromine.eqiad.wmnet instead of caesium.eqiad.wmnet
Do i care? You do if you are a "releaser" in one of the admin groups
who upload files to releases.wm.org.
Hi,
the backend of releases.wm.org has moved away from caesium.eqiad.wmnet over
to bromine.eqiad.wmnet. The reason was to get rid of yet another outdated
Ubuntu system and replace it with a Debian jessie system.
All the releases files in /srv/org and your /home directories have been
copied over,
everything should be like before, just use the new server name please.
The task for that was https://phabricator.wikimedia.org/T124261
While on it i made the directory index page look a bit nicer and sort
files differently so that new release versions are on top.
The details for that were in https://phabricator.wikimedia.org/T125164
Let me know if you see any issues,
Best, Daniel
--
Daniel Zahn <dzahn(a)wikimedia.org>
Operations Engineer
With the merge of Gerrit change 264309,[1] to be deployed with
1.27.0-wmf.12, note the following changes to the PHP interface around login
and account creation tokens:
- LoginForm::setLoginToken() and LoginForm::setCreateaccountToken() are
deprecated and no longer do anything. The token is automatically created
when fetched.
- LoginForm::getLoginToken() and LoginForm::getCreateaccountToken() now
return a MediaWiki\Session\Token object rather than a string. This object
implements __toString(), so automatic casting to a string is supported and
will likely mask this change for many uses.
- The token strings themselves are now similar to edit tokens: they're
longer, end in "+\", and include an embedded timestamp for expiration.
- Due to the embedded timestamp, tokens must now be compared using the
->match() method on the Token object. String equality comparison will no
longer work.
- It is no longer possible to determine if the token was not already
generated for the session by looking for an empty response from
LoginForm::getLoginToken() and LoginForm::getCreateaccountToken(). If
this is necssary (it shouldn't be), use the ->wasNew() method on the Token
object.
If your PHP code makes use of login or account creation tokens for some
reason, please check to see if your code needs updating for these changes.
For the record, a new method User::getEditTokenObject() has been added to
fetch edit tokens as MediaWiki\Session\Token objects as well, but
User::getEditToken() and User::matchEditToken() have not been changed or
deprecated at this time.
Note that API clients and other non-PHP users of these tokens are unlikely
to be broken by this change. See
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-January/0…
for details on changes to the API related to this change.
[1]: https://gerrit.wikimedia.org/r/#/c/264309/
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
As you may be aware, the reading team was unhappy with its current release
process and shared its rationale
<https://www.mediawiki.org/wiki/Reading/Web/Release_process/experiment#Ratio…>
for a different release process. This resulted in an experiment on Gather,
QuickSurveys, Cards and RelatedArticles where the team developed on the dev
branch by default. When the team was happy that the dev branch was stable,
it would tag a release and merge to master. The idea was to minimise the
deployment of incomplete features and SWAT deploys.
This process saw mixed success. Although we felt more comfortable and in
control of the code we shipped due to more time for designers and product
owners to input into our process it was clear there was an impedance
mismatch with the expectations in the MediaWiki developer community and for
a small team of 5, we were unable to keep up with the periodic releases of
extensions we were not actively maintaining.
As a result we are abandoning this experiment and going back to
the Mediawiki Way™ of releasing and merging directly to master.
When we work on new features, we will be more mindful of +2, marking the
initial commit of a chain of commits that requires sign off from a designer
and product owner with a -2.
We think this will be a better approach for everyone. Our only remaining
question is when and if to do release number bumps in future. We'll be back
with an answer about that shortly... ideas welcomed.
Thank you for your patience while we experimented and let us know if there
is anything else of interest to you in this experiment we have run.
Notes from post-mortem are on wiki
<https://www.mediawiki.org/wiki/Reading/Web/Notes/2016-Q3_Branching_strategy…>
I will be presenting at FOSDEM on the LiquidThreads to Flow conversion,
at 2016-01-30, 16:00 Belgium time:
http://www.timeanddate.com/worldclock/fixedtime.html?msg=FOSDEM+LiquidThrea…
It will be live-streamed at
https://live.fosdem.org/watch.php?room=H.2215%20(Ferrer) (from what I
can tell in advance).
Thanks,
Matt Flaschen
-------- Forwarded Message --------
Subject: Your speaking schedule at FOSDEM
Date: Fri, 15 Jan 2016 22:13:33 +0100 (CET)
From: FOSDEM Programme Team <speakers(a)fosdem.org>
Reply-To: speakers(a)fosdem.org
Organization: FOSDEM - https://fosdem.org/
To: Matt Flaschen <mflaschen(a)wikimedia.org>
CC: speakers(a)fosdem.org
Dear speaker,
Thank you for agreeing to speak at FOSDEM!
Our programme is now complete:
https://fosdem.org/2016/schedule/
This is your schedule:
.----------------------------------------------------------------------------.
| day | time | room | title
|
+------------+----------+-----------------+----------------------------------+
| 2016-01-30 | 16:00:00 | H.2215 (Ferrer) | Converting LiquidThreads to
Flow |
'------------+----------+-----------------+----------------------------------'
.---------------------------------------------.
| links |
+---------------------------------------------+
| https://fosdem.org/2016/schedule/event/flow |
'---------------------------------------------'
Please check these links carefully. If you already created an account at:
https://fosdem.org/submit
you can login and update the information if need be.
In particular, please upload a photograph if you have not already done
so and enter or update your biography.
Changes take a few minutes to reach the website - the time it was last
updated appears at the bottom of this page:
https://fosdem.org/2016/schedule/events/
If you find yourself unable to attend, please let your room's organiser
know this as soon as possible.
FOSDEM intends to record and stream the entire conference live - that's
over 300 hours of content! The recordings will be published under the
same licence as all FOSDEM content (CC-BY). You are agreeing to this by
taking part in the event.
Any slide decks you present should be uploaded by about half-an-hour
before the start of your talk so that people watching the live stream
can follow them locally if their video resolution leaves slide content
indistinct. (Our system does not hold back publication, so if you don't
want people to see them too far in advance, don't upload them yet.)
Projectors work at 1024x768 but expect slides (and any demonstrations)
to be scaled down to 720x576 for the video, so try to make them
readable at this lower resolution if you can.
Please don't forget to bring a VGA adaptor if you hope to present from a
laptop that only has a different type of output connector! We also
recommend bringing a spare copy of any slides on a USB stick.
As usual, we aim to provide free high-quality wireless network
connectivity throughout the event.
Best wishes,
The FOSDEM Programme Team
Good evening. For the past week, my bot has intermittently been seeing this
error when it tries to edit or upload:
API Error: Array
(
[code] => badtoken
[info] => Invalid token
[*] => See http://commons.wikimedia.org/w/api.php for API usage
)
It is unpredictable; it will occasionally fail for one thread, and then
work for a thread an hour later. Deleting the cookies has on occasion fixed
the issue for a few days.
Is there anything that can be done to fix this?
Magog
As we approach another quarterly planning cycle, I'd like to bring my
proposal for how we can improve our quarterly planning and review process.
https://www.mediawiki.org/wiki/Wikimedia_Engineering/Goals_Proposal
Do people support implementing these changes for the Q4 planning cycle? If
you have input, could you please participate in the discussion on the talk
page by Feb 5 (next Friday)?
- Trevor
https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-01-27
= 2015-01-27 =
== Product ==
=== Reading ===
==== Android ====
* Hotfix for login issues, v2.1.138, in production.
* v2.1.139 beta published for changes in Wiktionary API and removal of "m."
requests.
* Android saved synchronized articles implementation in progress (using
API's userjs feature).
* Even better memory profile coming soon.
==== iOS ====
* Evaluating pageviews API usage for "Trending/Top Articles" feature in 5.0
* Need to start evaluating impact of API usage in 5.0 (particularly
extensive use of extracts prop w/ search
* Login/Account creation integration meeting (AuthManager API changes in MW
core)
==== Web ====
* User page enhancements coming to mobile web (removal of
Special:UserProfile)
* PageImages API updates being examined (Fair use of images)
* Language overlay changes
* QuickSurveys enhancements
==== Reading Infrastructure ====
* Block: Security, are we good on https://gerrit.wikimedia.org/r/#/c/264309/
?
=== Community Tech ===
* Wrapping up work on Gadgets 2.0 https://www.mediawiki.org/wiki/Gadgets_2.0
** Could probably use a security review from Chris once it's done -
https://phabricator.wikimedia.org/T124943
* Collaborating with volunteers on Dead link rescue (bot) and Pagestats
tool (still in planning stage)
* Working on getting PageAssessments extension ready for testing as a
prototype https://www.mediawiki.org/wiki/Extension:PageAssessments
** Already had security review and DBA review
=== Editing ===
==== Language ====
* Got parallel corpora tables created
* Working on AbuseFilter
** Many articles not published due to AbuseFilter warnings/errors
** We are improving UI to better surface these warnings and what they mean
** Also trying to figure how to get more exact locations of the issues out
of AbuseFilter
** If any AbuseFilter experts around, I might have questions
* cxserver itself is ready for Node 4.2, but the Apertium packages are
still WIP (T106385), no estimate of when they'll be done.
** how urgent is this?
*** Answer: Don't have to do both at the same time.
==== Collaboration ====
* Moriel is working on having human-readable names for all Wikimedia wikis
available programatically in all languages. Initially, this will be used
for cross-wiki notifications, but it can potentially be used in many other
areas. https://phabricator.wikimedia.org/T121936
* Jaime approved the Flow dry run patch for the External Store migration.
It now needs to be reviewed by our team and then tested on Beta Cluster.
* I'll (Matt Flaschen) be at FOSDEM, and lead the MediaWiki stand
presence. I'm also presenting on the LiquidThreads to Flow conversion.
See wikitech-l for more information.
==== VisualEditor ====
* Blockers: https://phabricator.wikimedia.org/T58337 is blocked on review
from Krinkle for https://gerrit.wikimedia.org/r/#/c/259771/ and
https://gerrit.wikimedia.org/r/#/c/265878/ and so
https://gerrit.wikimedia.org/r/#/c/265879/
* Blockees: Only known blockee is Design Research, waiting on above patches
to land on Beta Cluster.
* Production deployment on shared feedback page and VE default-on for
another few wikis delayed from Monday due to the train; not yet scheduled.
==== Multimedia ====
* No known blockers or blockees.
=== Discovery ===
* found temp solution for load spikes, moved more_like traffic to another
cluster
** working on improving "more like" performance, may change results, will
a/b test https://phabricator.wikimedia.org/T124258
* working on yearly plan/budget
* started loading analytics data into ElasticSearch, full run takes ~12
hrs, may need to look for performance improvement
* Working on integrating completion search into SearchEngine API
* Blazegraph 2.0 is out, Wikidata Query service upgrading soon
* Blocked:
** need help from Ops for access analytics->codfw for
elastic20{01..24}.codfw.wmnet, er, I 'd rather not have ACLs on the routers
referring to non intra DC things. Why is that needed ? Task ? Same reason
we needed it before, we need to get data from analytics to ES machines and
this is the only way we found we can do it right now.
https://phabricator.wikimedia.org/T120281
eqiad access works, but codfw one does not.
== Advancement ==
=== Fundraising Tech ===
* Creating CI job to test DonationInterface on mw branch deployed on
payments cluster
** thanks Antoine!
* Working on new fraud filters
* More CiviCRM fixes and improvements
* Making code changes to expand Latin America fundraising from just Brazil
to six other countries
== Technology ==
=== Technical Operations ===
* Blocked: Research on ORES
* Blocked by: none
* Updates:
** Had an outage yesterday. all *.wikimedia.org was redirected to
wikimedia.org
** mira is now the deployment server, NOT tin
** Got an OTRS upgrade on Feb 3
** HHVM 3.11 packages are ready to go:
http://anonscm.debian.org/cgit/pkg-hhvm/hhvm.git/log/
** mobile traffic varnish clusters get folded into the text clusters.
** Need help with:
*** https://phabricator.wikimedia.org/T124649 module dependencies handling,
mediawiki core ?
*** https://phabricator.wikimedia.org/T124651 RELENG. phabricator is
misbehaving when a git repo is missing
*** https://phabricator.wikimedia.org/T124418 Investigate massive increase
in htmlCacheUpdate jobs in Dec/Jan
=== Services ===
* EventBus
:* extension emitting events live in prod
* Move to Jessie and Node 4.2
:* Graphoid and Citoid - done
:* CXServer - please check!
::* Apertium pkgs?
:* RELENG. CI support for Node 4.2
::* https://phabricator.wikimedia.org/T119143
:* RELENG. Migrate to Node 4.2 in BetaCluster
::* task to be created :P
=== Security ===
* More patches on the cluster; deploying updates for LanguageConverter this
week
* Keystone plugin development underway
=== Research ===
* Blocked: none
* Blocked by:
** ORES moving to new meso-level (Labs < Meso < Prod) support -- blocked on
Ops time to set up machines
*** See https://phabricator.wikimedia.org/T106867 -- working with Yuvi to
flesh out sub-tasks -- need to know who to CC
=== Release Engineering ===
* *Blocking*: YES (as of today ;-) )
* *Blocked*: none
* *Updates:*
** scap 3.0 will be tagged and packaged soon
*** Finishing work on puppet provider
** Shifting the MW train window starting next week to 2000 UTC (noon PST)
** Re-deploying 1.27.0-wmf.11 this week after last week's rollback due to
SessionManager issues
** Discussing ways to improve reliability and recoverability of train
deploys (tools and process)
** Annual planning all the things
I ran into an issue trying to save MediaWiki:Common.js I get this page not available (index.php?title=MediaWiki:Common.js&action=submit)
MediaWiki:Common.css save fine
Any Idea what I'm doing wrong?
Thank you!
Trying again from a different address
On 26 January 2016 at 01:04, Alex Monk <amonk(a)wikimedia.org> wrote:
> Forwarding to wikitech-l since this is not really specific to staff, but
> all shell users.
>
> On 25 January 2016 at 20:39, Ori Livneh <ori(a)wikimedia.org> wrote:
>
>> The X-Wikimedia-Debug header, for those of you who don't know, is an HTTP
>> request header that you can set on your requests (either manually, or by
>> using the Chrome[1] or Firefox[2] extensions). Requests bearing this header
>> are always treated as cache misses by Varnish, and they are always routed
>> to the same backend, mw1017.
>>
>> In addition to handling X-Wikimedia-Debug requests, mw1017 is also
>> configured as the sole application server backend for all requests to
>> test.wikimedia.org. This was set up before X-Wikimedia-Debug existed,
>> and as a debugging tool it is (IMO) inferior to it, because
>> X-Wikimedia-Debug allows you to test code changes against any production
>> wiki.
>>
>> What I've seen happen before is developers (like me -- I've done this
>> before) live-hack code on mw1017 to debug some issue that is only showing
>> up in production. This can cause testwiki to break, which annoys developers
>> and editors who use testwiki for testing things like Lua modules or editing
>> functionality on mobile apps.
>>
>> To reduce contention for mw1017, I propose that we do the following:
>>
>> 1) Keep testwiki, but don't special-case it in Varnish
>> (in other words, have testwiki requests go to the standard app server
>> pool)
>>
>> 2) Reserve mw1017 exclusively for X-Wikimedia-Debug requests
>>
>> 3) Add a service alias (appservers-debug.svc.eqiad.wmnet) for mw1017 and
>> update the varnish backend config to use that, rather than hard-code mw1017
>> in VCL.
>>
>> Thoughts?
>>
>> [1]:
>> https://chrome.google.com/webstore/detail/wikimediadebug/binmakecefompkjggi…
>> [2]:
>> https://addons.mozilla.org/en-US/firefox/addon/wikimedia-debug-header/
>>
>>
>> _______________________________________________
>> Engineering mailing list
>> Engineering(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/engineering
>>
>>
> --
> Alex Monk
> VisualEditor/Editing team
> https://wikimediafoundation.org/wiki/User:Krenair_(WMF)
>
The other day, someone came and renamed the Phabricator projects for
various skins from MediaWiki-skins-Foo to just Foo.
A few days later, someone else came and renamed them all back.
Since I'm a member of a few of these projects, I've gotten lots of email
about this, twice.
(Example: https://phabricator.wikimedia.org/project/profile/355/)
And the projects are inconsistently named at the moment, since both
persons missed a few spots:
https://phabricator.wikimedia.org/project/query/xTNAyyYaAY0U/#R
So, what should the names be?
--
Bartosz Dziewoński