The naming is due to how those are historically handled, non "project" wikis (eg: mediawiki and advisory as well as many others) are in the wikipedia area. You will notice this more on the secure server.

(In reply to comment #1)

The naming is due to how those are historically handled, non "project" wikis
(eg: mediawiki and advisory as well as many others) are in the wikipedia area.
You will notice this more on the secure server.

I know why they are in the wikipedia space in those areas, but I'm sure there's more to it that the system used on the secure server.

Reason being that the following wikis (and more) are in /wikipedia/ on secure but on on IRC:

• meta.wikimedia
• commons.wikimedia
• incubator.wikimedia
• strategy.wikimedia
• wikimania2006.wikimedia
• wikimania2007.wikimedia
• wikimania2008.wikimedia
• wikimania2009.wikimedia
• wikimania2010.wikimedia
• wikimania2011.wikimedia

All of the above are working irc channels on irc.wikimedia.org

So why the exception for those 4 ?

4 : mediawiki, advisory.wikimedia, species.wikimedia, pa.us.wikimedia

These can be fixed on a case-by-case basis by setting $wgRC2UDPPrefix in InitialiseSettings.php. After you change it, the IRC client will create the new channel when the first event comes through for that wiki.

(In reply to comment #4)

These can be fixed on a case-by-case basis by setting $wgRC2UDPPrefix in
InitialiseSettings.php. After you change it, the IRC client will create the new
channel when the first event comes through for that wiki.

This may sound stupid, but how about defaulting it to "#\$wgServer\t", since that's what it's trying to do anyway.

(instead of adding every exception manually, which is like the reverse of the wgDBname regex at the start.

also problems with readerfeedback.labs.wikimedia.org

Channel name in the wikimedi.irc is #readerfeddback-labs.wikimedia

[[m:User:Barras|Barras]]

Want to maybe check on wikitech for some consensus to this bug?

So to summarize, in prep. of a wikitech-l post:

IRC channels are historically in a domain-name fashion (but without a .org prefix), eg.:

• #commons.wikimedia
• #en.wikipedia
• #nl.wiktionary
• etc.

However the way wgRC2UDPPrefix does this is by reverse engeneering the logic based on wgDBname, $site and $lang, and does so fairly well but there are (imho too many) exceptions. None of them are surprising once you know how wgDBname is constructed (regexes, switches and stuff in the head of noc settings).

So since this is a long after initialization, how about just using wgServer for this ? Note that this may be problematic with edits made on the secure server, depending on how stuff is send and handled.

Now that I think of it, the 'wikipedia' word problem is also bugging other systems. Such as the several lazy implementations for urls that do http://$lang.$site (that cause bug 27911) which causes Server Not Found errors with icon embeds to stuff like http://foundation.wikipedia.org/apple-touch-icon.png (that hostname doesn't exist! yet there's a link to it in the head-section of all pages on those dbname "*wiki" wikis.

.. perhaps a better solution to fix this is to use wgServer instead of $lang.$site. Although it can't be used on the server server (yet), so perhaps a var like $wmfDomain can be constructed that is the real hostname (so it won't say mediawiki.wikipedia but mediaiki.org for instance) and use that instead.

It's funny how something simple like the domainname of the current wiki is not available... With https into relative urls and secure.wm.o gone, that part of the problem should become a moot point though.

Anyway back to the present and to this bug (which we may wanna wait fixing until after secure.wm.o is gone) - what're your thoughts on this ? using wgServer (or wmfDomain) bad ?

Additional inconsistently named channels:

donate.wikimedia.org -> #donate.wikimedia
#outreach.wikipedia -> #outreach.wikimedia
#quality.wikipedia -> #quality.wikimedia
#wikimania2010.wikipedia -> #wikimania2010.wikimedia
#wikimania2011.wikipedia -> #wikimania2011.wikimedia
#wikimania2012.wikipedia -> #wikimania2012.wikimedia
#wikimania2013.wikipedia -> #wikimania2013.wikimedia

*** Bug 41682 has been marked as a duplicate of this bug. ***

+ #wikidata.wikipedia -> #wikidata.wikimedia

We should have a checklist for wiki creation -- or please add this item ($wgRC2UDPPrefix) to the list if there's already an existing one.

https://gerrit.wikimedia.org/r/47307

(In reply to comment #13)

https://gerrit.wikimedia.org/r/47307

DO NOT MERGE unless an announcement has been made and tools given at least 31 days of time to address this.

There are many many bots that monitor wikis and given that:

• WMF has little to no investment in countervandalism
• Tools have gone unmaintained for years

it will take time to get to everybody in time.

Also, I propose we do this in 2 phases:

1. Change default from lang.site to hostname

By setting the default in InitialiseSettings.php to false.
And in CommonSettings.php the logic Reedy proposed if prefix===false.

Then, in the same commit, add entries to the array in InitialiseSettings for all wikis where hostname !== lang.site (if not already in there).

This phase can be done without announcement as it will have no effective change. It only changes the default for new wikis in the future.

2. When agreed on and given 31 days with announcement, phase out the historical overrides added prior or during phase 1.

Well, it actually *can* be merged *if* there are manually created redirects (/mode +if) from old names, which can then stay for a even longer period than a month.

Footnote for naming on dbnames - there was a call to name dbases consistently according to the domain name too, so they could also be easily predicitble and constructible. Bear that in mind, please, maybe join these two steps together. (I'll try to find the relevant bug for it, can't find it now.)

And now #login.wikipedia. Can we at least fix that one before the site starts being used?

(In reply to comment #16)

And now #login.wikipedia. Can we at least fix that one before the site starts
being used?

You know, there's going to be very few edits made to that wiki....

Thehelpfulonewiki wrote:

(In reply to comment #15)

Well, it actually *can* be merged *if* there are manually created redirects
(/mode +if) from old names, which can then stay for a even longer period
than a
month.

Who can create these redirects on our IRC server?

(In reply to comment #18)

(In reply to comment #15)

Well, it actually *can* be merged *if* there are manually created redirects
(/mode +if) from old names, which can then stay for a even longer period
than a
month.

Who can create these redirects on our IRC server?

Also, it's important to look into whether the libraries out there can handle with redirects (both on existing connections and for new connections).

The two libraries most used in this context are:

• SmartIrc4net (used by [[m:CVN]]'s CVNBot) https://github.com/meebey/SmartIrc4net
• python-irclib/ircbot/SingleServerIRCBot (used by pywikibot) https://bitbucket.org/jaraco/irc https://github.com/jaraco/irc

Neither appears to have handling for mode 'f' on channels, or have any mention of the word "redirect" or "forward" anywhere in their codebase.

(In reply to Krinkle from comment #19)

Also, it's important to look into whether the libraries out there can handle
with redirects (both on existing connections and for new connections).

The two libraries most used in this context are:

• SmartIrc4net (used by [[m:CVN]]'s CVNBot) https://github.com/meebey/SmartIrc4net
• python-irclib/ircbot/SingleServerIRCBot (used by pywikibot) https://bitbucket.org/jaraco/irc https://github.com/jaraco/irc

Neither appears to have handling for mode 'f' on channels, or have any
mention of the word "redirect" or "forward" anywhere in their codebase.

/mode +if redirects whoever automatically on server side. (aka it does not work like 301/302 redirs in HTTP which require client to act)

Now that we're working on RCStream, I think it's best to just keep the old irc channels the way they are until we (eventually) shutdown irc.wikimedia.org. No need in nitpicking over channel names and having people migrate. What we really want is for people to migrate to stream.wikimedia.org.

The few configuration lines to keep the channel names different on irc.wikimedia.org aren't that troublesome to just keep around.

https://wikitech.wikimedia.org/wiki/stream.wikimedia.org
https://wikitech.wikimedia.org/wiki/RCStream

We're still busy installing it in Eqiad data centre, but coming online very soon now.

(In reply to Krinkle from comment #21)

Now that we're working on RCStream, I think it's best to just keep the old
irc channels the way they are until we (eventually) shutdown
irc.wikimedia.org. No need in nitpicking over channel names and having
people migrate. What we really want is for people to migrate to
stream.wikimedia.org.

You don't need anybody to migrate. As mentioned in comment #20, the server handles that automatically itself.

(In reply to Danny B. from comment #20)

/mode +if redirects whoever automatically on server side

Only on join unless you cycle the channel, though