be-x-old.wikipedia.org has been waiting to be renamed since 2007, so apparently it's not a quick process.

On Tue, Aug 25, 2015 at 10:24 PM, Kartik Mistry kartik.mistry@gmail.com wrote:

On Wed, Aug 26, 2015 at 10:50 AM, Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote:

...

In a few projects the language code in the domain is different from the actual language code: 'als' is a code for Tosk Albanian, but als.wikipedia.org is written in Alemanic; 'no' is a code for both Bokmal Norwegian and Nynorsk Norwegian, but no.wikipedia.org is only Bokmal;

and

...

there are several other examples.

In the past when requests to rename such domains were raised, the usual replies were along the lines of "it's impossible" or "it's not worth the technical effort", but I don't know the details.

Also see: https://phabricator.wikimedia.org/T21986 (Wikis waiting to be renamed (tracking))

-- Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_ {kartikm, 0x1f1f}.wordpress.com

---

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

(this is not an official response, just my opinion after some research on the topic)

Due to internal (and growing) complexity of the mediawiki software, and WMF installation (regarding numerous plugins and services/servers), this is a non trivial task. It also involves many moving pieces and many people- network admins (dns), general operations (load control/downtime), dbas (import/export), services, deployment engineers and developers (mediawiki configuration changes, patches).

What's worse, is that it would almost certainly create downtime for the wikis involved (not being able to edit) -specially given that it is not a common operation-, and some of them are smaller communities, and I would be worried be to annoy or discourage editing on those wikis (when we want the opposite!).

It would be great to have someone in contact with the community so that we can identify which sites have a great consensus about renaming the wiki, and are perfectly informed about the potential problems and still are ok to go forward. Maybe someone in Community engagement can evaluate risks vs. return?

On Wed, Aug 26, 2015 at 9:53 AM, Antoine Musso hashar+wmf@free.fr wrote:

Le 26/08/2015 07:20, Amir E. Aharoni a écrit :

...

In the past when requests to rename such domains were raised, the usual replies were along the lines of "it's impossible" or "it's not worth the technical effort", but I don't know the details.

Is this still correct in 2015?

As pointed out: https://phabricator.wikimedia.org/T21986

For what it is worth, in 2011 JeLuF wrote a list of actions needed to rename a wiki. It is outdated nowadays but that is sufficient to state renaming a wiki is a non-trivial task: https://wikitech.wikimedia.org/wiki/Rename_a_wiki

It would surely consume a lot of engineering time to come up with a proper migration plan and actually conduct them. I am not sure it is worth the time and money unfortunately.

-- Antoine "hashar" Musso

---

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

Thank you for raising the discussion!

On Wed, Aug 26, 2015 at 1:41 PM, This, that and the other < at.light@live.com.au> wrote:

I also think many of the communities, especially if small, would view a

brief period of downtime as an acceptable tradeoff

for having their domain name corrected. Especially "be-x-old", I've

always thought that one was pretty ugly, and wouldn't

be surprised if the Taraškievica Belarusian Wikipedia community felt the

same way.

On behalf of the be-x-old community, I can ensure that such a rename is really demanded and would find a great support, even if this causes hours or days of downtime. If a formal community discussion on this topic is required, it can definitely be arranged.

By the way, back in 2007, be-x-old was already renamed once, from be to be-x-old. As far as I remember, this caused periods of downtime and read-only, however eventually all the links, interwikis and templates were corrected manually or semi-automatically, so this added some work but was not a big problem back then.

Cheers, zedlik

On Wed, Aug 26, 2015 at 1:41 PM, This, that and the other < at.light@live.com.au> wrote:

Thanks for bringing this up, Amir.

I would point out that since there are such a lot of wikis waiting to be renamed, there is an opportunity for economy of scale here. If all the departments/people you list were able to set aside a couple of days to sit down together and rename the 15+ wikis waiting to be renamed, having figured out a process and renamed a trial wiki beforehand, I think it could be made worthwhile.

I also think many of the communities, especially if small, would view a brief period of downtime as an acceptable tradeoff for having their domain name corrected. Especially "be-x-old", I've always thought that one was pretty ugly, and wouldn't be surprised if the Taraškievica Belarusian Wikipedia community felt the same way.

I agree that getting community engagement/community liaisons involved and talking with relevant developers/ops folks and the affected editing communities would be a good next step.

TTO

(Sorry for not replying inline: my news client is pretty dumb, as you can probably guess from the header line below.)

-- "Jaime Crespo" wrote in message news:CABaSSrL0hm1T9sHd-qh1npK8J-OPUPttBr6_ muDAN3C5bWu25Q@mail.gmail.com...

(this is not an official response, just my opinion after some research on the topic)

Due to internal (and growing) complexity of the mediawiki software, and WMF installation (regarding numerous plugins and services/servers), this is a non trivial task. It also involves many moving pieces and many people- network admins (dns), general operations (load control/downtime), dbas (import/export), services, deployment engineers and developers (mediawiki configuration changes, patches).

What's worse, is that it would almost certainly create downtime for the wikis involved (not being able to edit) -specially given that it is not a common operation-, and some of them are smaller communities, and I would be worried be to annoy or discourage editing on those wikis (when we want the opposite!).

It would be great to have someone in contact with the community so that we can identify which sites have a great consensus about renaming the wiki, and are perfectly informed about the potential problems and still are ok to go forward. Maybe someone in Community engagement can evaluate risks vs. return?

On Wed, Aug 26, 2015 at 9:53 AM, Antoine Musso hashar+wmf@free.fr wrote:

Le 26/08/2015 07:20, Amir E. Aharoni a écrit :

...

...

In the past when requests to rename such domains were raised, the usual replies were along the lines of "it's impossible" or "it's not worth the technical effort", but I don't know the details.

Is this still correct in 2015?

As pointed out: https://phabricator.wikimedia.org/T21986

For what it is worth, in 2011 JeLuF wrote a list of actions needed to rename a wiki. It is outdated nowadays but that is sufficient to state renaming a wiki is a non-trivial task: https://wikitech.wikimedia.org/wiki/Rename_a_wiki

It would surely consume a lot of engineering time to come up with a proper migration plan and actually conduct them. I am not sure it is worth the time and money unfortunately.

-- Antoine "hashar" Musso

---

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

-- Jaime Crespo http://wikimedia.org _______________________________________________ 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

On Wed, Aug 26, 2015 at 3:46 PM, Alex Monk krenair@gmail.com wrote:

I'm not sure why database changes would be involved in a domain-only change? It should be simple enough to get the new domain set up in DNS and apache config, tell multiversion how to map it to the old DB name (there's an array in setSiteInfoForWiki that does this bit), and once it's all

Not a developer, but AFAIK It requires a patch, that is proposed (by Reedy, I think), but not implemented. And there are other blockers like non-main DB dependencies on FlowDB, external storage and X1 plugins, plus some names inside the rows. But I am not the mediawiki expert. Feel free to contribute to the above mentioned tickets.

On 8/26/15, Jaime Crespo jcrespo@wikimedia.org wrote:

On Wed, Aug 26, 2015 at 3:46 PM, Alex Monk krenair@gmail.com wrote:

...

I'm not sure why database changes would be involved in a domain-only change? It should be simple enough to get the new domain set up in DNS and apache config, tell multiversion how to map it to the old DB name (there's an array in setSiteInfoForWiki that does this bit), and once it's all

Not a developer, but AFAIK It requires a patch, that is proposed (by Reedy, I think), but not implemented. And there are other blockers like non-main DB dependencies on FlowDB, external storage and X1 plugins, plus some names inside the rows. But I am not the mediawiki expert. Feel free to contribute to the above mentioned tickets.

-- Jaime Crespo http://wikimedia.org _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I really don't know what in MediaWiki would be complicated. After all, we used to serve stuff from secure.wikimedia.org, (A different domain) and nothing exploded. The worst bit was it split parser cache due to magic words like {{SERVER}}. If we can serve from two different domains, surely we could serve from two domains, delete 1, and then just serve from the new domain.

Actually renaming the database name would probably cause a lot of problems, but I don't see why we would want to do that.

imo, Anywhere in MediaWiki proper (e.g. Not counting WMF's overly complicated config management system [yeah yeah, technically part of MW, but you get my drift...]) that would be broken by changing domains, and wouldn't instantly be fixed by changing $wgServer, should be considered a bug. I am unaware of any such bugs at this time. -- -bawolff

On Wed, Aug 26, 2015 at 9:02 PM Alex Monk krenair@gmail.com wrote:

On 27 August 2015 at 04:57, Brian Wolff bawolff@gmail.com wrote:

...

If we can serve from two different domains, surely we could serve from two domains, delete 1, and then just serve from the new domain.

That's my plan with https://gerrit.wikimedia.org/r/#/c/233972/ - I've added it to the puppet SWAT window later today. When ops have approved it, it should just be a case of me setting up MediaWiki to use the correct database name, and then wgServer etc. can be changed and the old domain can be redirected.

Personally I've long thought that doing it this way (just swapping the domain, leaving everything else identical) is the lazy way and is likely to bite us in the ass later.

Otherwise: why the heck didn't we do it 10 years ago?

$staticMappings in Multiversion is a hack. I would be loathe to extend the practice further.

-Chad

On Wed, Aug 26, 2015 at 9:53 AM, Antoine Musso hashar+wmf@free.fr wrote:

It would surely consume a lot of engineering time to come up with a proper migration plan and actually conduct them. I am not sure it is worth the time and money unfortunately.

As noted by Eric Lippert, “If you're going to make a backward-compatibility-breaking change, no time is better than now; things will be worse in the future.” [1]

If “we” are not going to invest the time and money _now_, we are probably _never_ going to do that, so if that is the case, let’s state that explicitly, close the relevant bugs as WONTFIX and stop making the impression the renaming could happen sometimes later.

-- [[cs:User:Mormegil | Petr Kadlec]]

[1] http://www.informit.com/articles/article.aspx?p=2425867

On Wed, Aug 26, 2015 at 3:19 PM, MZMcBride z@mzmcbride.com wrote:

That said, creating a wiki is actually fairly easy, so maybe we should investigate a large-scale export and import process instead of renaming.

My answer already assumed that as the only way, hence the downtime. :-)