Page MenuHomePhabricator

Remove secure.wikimedia.org
Closed, DeclinedPublic

Description

It's long gone. Kill it, kill it with fire

Event Timeline

Reedy raised the priority of this task from to Lowest.
Reedy updated the task description. (Show Details)
Reedy added a project: SRE.
Reedy added a subscriber: Reedy.

Change 257510 had a related patch set uploaded (by Reedy):
Remove secure.wikimedia.org from apacheo

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

Change 257513 had a related patch set uploaded (by Reedy):
Remove secure.wikimedia.org from DNS

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

Uhh, lets not break links please? :/

What links? Where? See T119274 for amount of incoming links

Traffic is irrelevant imho. This was a user-facing service for many years. See also https://meta.wikimedia.org/wiki/Don't_delete_redirects. It's not like bits.wikimedia.org or other internal services.

They may be used in old discussions, mailing lists, talk pages, tweets, edit summaries, printed form etc. Just because they don't happen often doesn't mean they no longer exist.

I guess we should call it declined then...

I guess we should call it declined then...

Bummer :(

So.... anyone wants to make a decision (kill vs. decline)?

Change 257510 abandoned by Reedy:
Remove secure.wikimedia.org from apache

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

Change 257513 abandoned by Reedy:
Remove secure.wikimedia.org from DNS

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

@BBlack: Any idea who could (be in a position to) make a decision (kill vs. decline)?

I'm normally in favor of removing cruft when we can, but this was a semi-canonical way to access our domains for a long time, and it still has functional redirects to our current canonical HTTPS URLs. There's probably a lot of other more-important cruft to kill before we go after this, which will give more time for old usage of it to die off naturally. So I'd say decline for now, revisit later (later as in a year or two probably).