Re: [Wikitech-l] Close test2wiki?

[Alex Monk]

+1 from me for closing it. Do people have important things there, or can it
be 'deleted'?

On 27 January 2016 at 22:01, Chad  wrote:

> On Wed, Jan 27, 2016 at 2:00 PM James Forrester 
> wrote:
>
> > On 27 January 2016 at 13:57, Ori Livneh  wrote:
> >
> > > The setup of test2.wikipedia.org is no longer meaningfully different
> > from
> > > test.wikipedia.org. Is there a good reason for keeping test2?
> > >
> >
> > ​I'd be happy for it to be closed.​
> >
> >
> It was only setup ever so we could write/test het deploy.
>
> It became way less useful after we stopped serving test(1)
> from NFS.
>
> Close it.
>
> -Chad
> ___
> 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] Close test2wiki?

[James Forrester]

On 27 January 2016 at 14:18, Alex Monk  wrote:

> +1 from me for closing it. Do people have important things there, or can it
> be 'deleted'?
>

​We could just move all the content into testwiki and redirect the ​domain.
;-)

​J.
-- 
James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Close test2wiki?

[Legoktm]

On 01/28/2016 08:57 AM, Ori Livneh wrote:
> The setup of test2.wikipedia.org is no longer meaningfully different from
> test.wikipedia.org. Is there a good reason for keeping test2?

Especially when debugging and testing cross-wiki features, it is
extremely useful to have two test wikis to use. MassMessage,
GlobalCssJs, GlobalUserPage, and now cross-wiki notifications were all
initially deployed using testwiki as the "central" wiki, and test2wiki
as a "client" wiki.

Maybe testwikidatawiki could be used in place of test2wiki, but that's
already a bit special...

-- Legoktm

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Close test2wiki?

[Dan Duvall]

There appears to be one periodic Jenkins job running against test2wiki, and
it just started failing today, so we should investigate why.[1] Release
Engineering will look into moving this job to testwiki, but please don't
shut down test2wiki just yet.

[1]
https://integration.wikimedia.org/ci/view/BrowserTests/view/-Dashboard/job/browsertests-PdfHandler-test2.wikipedia.org-linux-firefox-sauce/

On Wed, Jan 27, 2016 at 1:57 PM, Ori Livneh  wrote:

> The setup of test2.wikipedia.org is no longer meaningfully different from
> test.wikipedia.org. Is there a good reason for keeping test2?
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Dan Duvall
Software Engineer
Wikimedia Foundation 
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Close test2wiki?

[Derk-Jan Hartman]

3 things come to mind. Not so long ago an invitation was sent to wiki 
communities to use that specific server for VE single edit tab testing. I think 
that should be taken into account. Since this feature has not yet landed in 
production, people might still be using that link to evaluate and would be 
surprised by it suddenly being gone.

And judging from RecentChanges, several editors use it regularly to develop 
scripts, lua or MediaWiki tests etc..

Some people who are admin on test2 or have other elevate rights, might not have 
those rights on test.wp.org

DJ


> On 27 jan. 2016, at 23:18, Alex Monk  wrote:
> 
> +1 from me for closing it. Do people have important things there, or can it
> be 'deleted'?
> 
> On 27 January 2016 at 22:01, Chad  wrote:
> 
>> On Wed, Jan 27, 2016 at 2:00 PM James Forrester 
>> wrote:
>> 
>>> On 27 January 2016 at 13:57, Ori Livneh  wrote:
>>> 
 The setup of test2.wikipedia.org is no longer meaningfully different
>>> from
 test.wikipedia.org. Is there a good reason for keeping test2?
 
>>> 
>>> ​I'd be happy for it to be closed.​
>>> 
>>> 
>> It was only setup ever so we could write/test het deploy.
>> 
>> It became way less useful after we stopped serving test(1)
>> from NFS.
>> 
>> Close it.
>> 
>> -Chad
>> ___
>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Close test2wiki?

[Dan Garry]

On 27 January 2016 at 17:16, Legoktm  wrote:

> Especially when debugging and testing cross-wiki features, it is
> extremely useful to have two test wikis to use. MassMessage,
> GlobalCssJs, GlobalUserPage, and now cross-wiki notifications were all
> initially deployed using testwiki as the "central" wiki, and test2wiki
> as a "client" wiki.
>

That sounds like a good reason to keep it, especially since global
notifications is an active, ongoing work. Perhaps, as an alternative to
shutting it down, we should just make it clearer that test2.wikipedia.org
is primarily intended for that purpose on that wiki's main page (or
anywhere else thought appropriate). If there's some specific overhead to
keeping test2 alive that might outweigh that benefit, now would seem to be
the time to make it clear. :-)

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2015-01-27 Scrum of Scrums notes

[Grace Gellerman]

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:
*** 

[Wikitech-l] Changes in Quarterly Planning

[Trevor Parscal]

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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Changes to token system?

[Magog The Ogre]

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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Alex Monk]

On 28 January 2016 at 02:15, Legoktm  wrote:

> Hi,
>
> On 01/27/2016 12:46 PM, Matthew Flaschen wrote:
> > On 01/25/2016 03:16 PM, Rob Lanphier wrote:
> >> In the short-term, I believe a non-Wikimedia focused subgroup of ArchCom
> >> may make sense.  The declining MediaWiki use outside of Wikimedia has
> >> been
> >> a longstanding problem for us, but not the biggest problem.
> >
> > Are there stats that show a decline?  Just curious.
>
> These aren't exactly stats, but I think the Google Trends graph of
> "MediaWiki" vs. "Confluence" shows a relevant picture:
> <
> https://www.google.com/trends/explore#q=mediawiki%2C%20confluence=q=Etc%2FGMT-11
> >
>

Perhaps relevant, but that's not at all a complete picture of MediaWiki's
use. MediaWiki is linked to at the bottom of every Wikipedia page, and a
lot of interested users are going to be able to remember the domain name
without going through Google. Download traffic (direct from mw.o, but also
through OS package managers) would be a more useful indication.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Legoktm]

Hi,

On 01/27/2016 12:46 PM, Matthew Flaschen wrote:
> On 01/25/2016 03:16 PM, Rob Lanphier wrote:
>> In the short-term, I believe a non-Wikimedia focused subgroup of ArchCom
>> may make sense.  The declining MediaWiki use outside of Wikimedia has
>> been
>> a longstanding problem for us, but not the biggest problem.
> 
> Are there stats that show a decline?  Just curious.

These aren't exactly stats, but I think the Google Trends graph of
"MediaWiki" vs. "Confluence" shows a relevant picture:


-- Legoktm

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Proposal regarding the future of X-Wikimedia-Debug and testwiki

[Ori Livneh]

On Tue, Jan 26, 2016 at 11:58 PM, Mukunda Modell 
wrote:

> I think it would be very useful to have a way to, in addition to
> cache-busting, also force the request to be served from the pre-production
> branch rather that the current production branch. This way changes on the
> prod+1 branch can be conveniently tested on any wiki (not just testwiki)
> while disregarding the version specified in wikiversions.
>

Well, there is a way: you can edit /srv/mediawiki/wikiversions.php on
mw1017 to change the mapping of wikis to branches, and set the
X-Wikimedia-Debug header to ensure your request gets handled by mw1017.
Making this more convenient would be very risky, because it would mean that
two different versions of the code are transacting with data on shared
storage backends, each with the presumption of being the only game in town.
And this state could be triggered by anyone, with no !logging or
coordination.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] INFO: Reading web release process update

[Greg Grossmeier]

> Feature flagging or using feature branches for certain things may be a way
> to go for certain things, we're keeping that in mind definitely, thanks for
> the reminder Greg.

Just be clear: feature branches aren't feature flags and take you back
to a place closer to a 'dev' branch :).

> I agree with you regarding releases Gergo. The good thing about the
> *release*s was mainly the curated changelog of changes for that release. A
> proposal I like is do the changelog every week with the train before the
> release branch is done. We'll need to establish owners for being effective
> at doing that.

It looks like the release notes[0] are just git short logs, yes? Or is
the HISTORY file not what you are referring to (I only did a quick
look)?

If it is just the git shortlog, take a look here:
eg: https://www.mediawiki.org/wiki/MediaWiki_1.27/wmf.11#MobileFrontend

Those pages are automatically created and posted every week with the
train, for free (by RelEng).

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] Saving MediaWiki:common.js

[Legault, Phillip [ITSUS]]

I'm seeing this error in the php log file
[Wed Jan 27 13:53:04.030488 2016] [:error] [pid 29314] [client 
10.45.13.185:55154] PHP Warning:  filemtime(): stat failed for 
/app/mediawiki/mw/composer.lock in 
/app/mediawiki/mw/extensions/Bootstrap/src/ResourceLoaderBootstrapModule.php on 
line 210, referer: /index.php?title=MediaWiki:Common.js=submit

-Original Message-
From: Legault, Phillip [ITSUS] 
Sent: Thursday, September 17, 2015 3:03 PM
To: Wikimedia developers
Subject: RE: [Wikitech-l] Saving MediaWiki:common.js

Sorry it took me a while to get back to this.
[Thu Sep 17 14:42:22 2015] [error] [client 10.22.165.73] File does not exist: 
/app/mediawiki/mw/skins/chameleon/kai_stars-dev.png, referer: 
server/index.php?title=MediaWiki:Common.js=edit

I rebuilt the database from my production system that is working and I'm still 
getting this error.



-Original Message-
From: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Brian Wolff
Sent: Wednesday, August 26, 2015 5:31 PM
To: Wikimedia developers
Subject: Re: [Wikitech-l] Saving MediaWiki:common.js

Did you check your php error log (And make sure that php error logging, 
particularly of fatal errors is enabled).

Check also your web server error log (if php segfaults or something, it would 
show up there)

--
-bawolff

On 8/26/15, Legault, Phillip [ITSUS]  wrote:
> Yes it is a private site
>
> I don't get any errors, I enable debug and still nothing
>
>
>
> MediaWiki  1.23.10
>
>
>
>
>
>
>
>
>
>
>
> -Original Message-
> From: wikitech-l-boun...@lists.wikimedia.org
> [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Andre 
> Klapper
> Sent: Wednesday, August 26, 2015 4:55 PM
> To: Wikimedia developers
> Subject: Re: [Wikitech-l] Saving MediaWiki:common.js
>
>
>
> Hi Phillip,
>
>
>
> On Wed, 2015-08-26 at 19:38 +, Legault, Phillip [ITSUS] wrote:
>
>> I ran into an issue trying to save MediaWiki:Common.js I get this 
>> page
>
>> not available
>
>> (index.php?title=MediaWiki:Common.js=submit)
>
>>
>
>> MediaWiki:Common.css save fine
>
>
>
> On some Wikimedia site (which one)? Or a private wiki?
>
>
>
> Is that the complete error message displayed (if not: please make sure 
> to not post private data like your IP adress)?
>
>
>
> Thanks,
>
> 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
> ___
> 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

[Wikitech-l] Close test2wiki?

[Ori Livneh]

The setup of test2.wikipedia.org is no longer meaningfully different from
test.wikipedia.org. Is there a good reason for keeping test2?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Close test2wiki?

[James Forrester]

On 27 January 2016 at 13:57, Ori Livneh  wrote:

> The setup of test2.wikipedia.org is no longer meaningfully different from
> test.wikipedia.org. Is there a good reason for keeping test2?
>

​I'd be happy for it to be closed.​

​J.
-- 
James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Close test2wiki?

[Chad]

On Wed, Jan 27, 2016 at 2:00 PM James Forrester 
wrote:

> On 27 January 2016 at 13:57, Ori Livneh  wrote:
>
> > The setup of test2.wikipedia.org is no longer meaningfully different
> from
> > test.wikipedia.org. Is there a good reason for keeping test2?
> >
>
> ​I'd be happy for it to be closed.​
>
>
It was only setup ever so we could write/test het deploy.

It became way less useful after we stopped serving test(1)
from NFS.

Close it.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Changes to token system?

[Gergo Tisza]

On Wed, Jan 27, 2016 at 8:46 PM, Magog The Ogre 
wrote:

> 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
>

Yes, session handling changed significantly; there was an announcement two
weeks ago with details [1].
The changes caused a handful of bots to misbehave; so far we have
identified two causes:
- some bots had a simplistic way of handling cookies that did ignored
expiration dates. The details of exactly when cookies are expired during a
login sequence have changed, and this confused those bots.
- some bots sent HTTP requests. Wikimedia officially dropped HTTP support
almost a year ago, but in practice HTTP POST requests are still accepted.
Last week started setting the 'secure' flag on all cookies which also broke
bots.

These changes have been reverted for now, but if your bot was affected,
please fix it. Bots should send all requests through HTTPS and they should
use RfC 6265 compliant cookie handling (when in doubt, use cURL cookie jars
or the standard HTTP library of your language (e.g. requests in Python);
those tend to get it right.

You can find more details in the Phabricator task tracking the issue,
T124252 [2]. If you are still seeing problems, please report them with more
details there (ideally the full API request & response, with passwords and
session and token cookies removed).


[1]
https://lists.wikimedia.org/pipermail/wikitech-l/2016-January/084501.html
[2] https://phabricator.wikimedia.org/T124252
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] INFO: Reading web release process update

[Joaquin Oltra Hernandez]

Feature flagging or using feature branches for certain things may be a way
to go for certain things, we're keeping that in mind definitely, thanks for
the reminder Greg.

I agree with you regarding releases Gergo. The good thing about the
*release*s was mainly the curated changelog of changes for that release. A
proposal I like is do the changelog every week with the train before the
release branch is done. We'll need to establish owners for being effective
at doing that.

On Wed, Jan 27, 2016 at 12:43 AM, Gergo Tisza  wrote:

> On Tue, Jan 26, 2016 at 2:11 PM, Jon Robson  wrote:
>
> > 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.
> >
>
> Who is the target audience of release numbers? If it is third-party wikis,
> they will probably only care about release branches (REL1_26 etc) and you
> don't have to do anything about that (except backporting fixes for
> especially nasty bugs), extension branches get split automatically whenever
> there is a new MediaWiki release.
>
> On the topic of +2 vs. accepting tasks in Scrum, synchronizing the scrum
> schedule with the release process (so that sprints start on Tuesday and end
> on Monday) reduces the pain. Although if you use two-week sprints that's
> probably less useful.
> ___
> 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] [Engineering] Proposal regarding the future of X-Wikimedia-Debug and testwiki

[Mukunda Modell]

On Wed, Jan 27, 2016 at 2:17 AM, Ori Livneh  wrote:

>
> Well, there is a way: you can edit /srv/mediawiki/wikiversions.php on
> mw1017 to change the mapping of wikis to branches, and set the
> X-Wikimedia-Debug header to ensure your request gets handled by mw1017.
> Making this more convenient would be very risky, because it would mean that
> two different versions of the code are transacting with data on shared
> storage backends, each with the presumption of being the only game in town.
> And this state could be triggered by anyone, with no !logging or
> coordination.
>

We really shouldn't be making the assumption that only a single version is
running at any given time. We are moving towards gradual / canary
deployments, with a portion of traffic hitting a new branch while the
remainder hits the old branch.  It's currently safe to assume that any
version is the only game in town and it's only going to get worse.

Anyone who is currently operating on that kind of assumption is being
reckless. Any time new code is changing assumptions about the structure of
shared storage, it needs to be rigorously reviewed and carefully protected
from premature release.  Deployments aren't at all atomic now, as far as I
know they never have been.

As a release engineer I see it as a failure on the part of my team if we
allow code to go out without proper gating of potentially destructive or
disruptive storage format changes.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l