Page MenuHomePhabricator

Switch WikiHiero to Hierator
Closed, DeclinedPublic

Description

This is a master ticket for new shiny vector hieroglyphs!

A few links:

Event Timeline

MaxSem created this task.Mar 24 2015, 6:51 PM
MaxSem raised the priority of this task from to Medium.
MaxSem updated the task description. (Show Details)
MaxSem added a project: WikiHiero.
MaxSem added a subscriber: MaxSem.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 24 2015, 6:51 PM
Aklapper set Security to None.
faidon added a subscriber: faidon.Jun 20 2015, 12:07 AM

We have turned this down multiple times and it seems it keeps coming back, so for the record: to my knowledge, Hierator is a service written in Java and Java (& JVM) is not one of the production platforms we support. Therefore, this cannot go forward.

So far, node.js has been the only one we do support, alongside our PHP monolith (that said, rules can always have exceptions, if a valid case is made). Also note that this is obviously not the rule for the third-party software that we use — usually these are backed by their upstreams, which we often judge by their responsiveness and size, plus usually a team involved to integrate with such software and deploy it.

In my opinion, we cannot simply support nor encourage services written in arbitrary languages, as chosen by individual developers or even teams. There are non-trivial maintenance costs into adding languages and frameworks into our mix, both from an operational and from an organizational point of view (domain expertise, standardization, silos, bus factors etc.), a danger that was even acknowledged in the initial SOA RFC.

Even large and more diverse organizations enforce a choice between 2-3 languages and develop common infrastructure for it. We can certainly discuss adding Java and/or JVM into the mix and that would be a valid conversation, in my opinion. We'd still have to weight this against its initial & running costs, as well as other choices for languages that we may have (others have proposed Go, Rust, Erlang and Haskell in the past). Even though my team has stakes in that conversation, I believe it's a conversation that we should be having both as an organization-with-a-budget, and as a community, as it cuts through multiple different requirements across the board.

In any case, even if Java was accepted, it currently requires an investment in preparing a "Java cluster" among other things, which I'm not sure we should be making just for the benefit of better hieroglyphics. It seems like a big price to pay for a small benefit and does not, in mind, fit with my understanding of WMF's annual plan.

(I'm honestly very sorry to be a negative force — I'm sure you've invested a lot into this and would like to see it move foward.)

  1. This was extensively discussed and approved in an RFC.
  2. We already run a ton of Java apps, don't we?
  3. Gabriel offered to run it on SCA so no extra hardware is needed (also because it's really low-load).

I realize this is not very clear, but the RFC decision is not binding for deploying this. The architecture committee is not a foundation body, does not have a budget and does not/cannot control resources. It can advise and provide direction but cannot assign work to people nor allocate resources. Plus, it's the MediaWiki archcom; having something accepted for MediaWiki does not necessarily mean having it accepted for running in Wikimedia's production.

I'm also surprised to hear about Gabriel — he cannot offer such a thing, as what runs and does not run on SCA is not his call. Perhaps you may have misunderstood his offer (which could have been e.g. helping you run it and deploy it on SCA). Nevertheless, I wasn't referring specifically to the hardware resources for this; I do realize it's a small service with little HW requirements.

As to your second point, I think I've sufficiently addressed the difference with third-party Java apps vs. in-house software.

Regarding @faidon's objections in T93787#1384436

If MaxSem contributed Hierator ("a Java servlet that renders Ancient Egyptian texts into images", sounds generic) back to the JSesh project and they adopted it, it seems it would then be "third-party software that we use" backed by its upstream, and thus similar to all the other Java (Elasticsearch, Hadoop, Gerrit, Jenkins, etc.) that WMF operates. Would the blocker then be identifying "the team involved to integrate with such software and deploy it"?

I'm not arguing, just seeking clarification. (Plus, I was confused about a project named JSesh that isn't JavaScript :-/ )

How will the RFC be put into effect then? Hieroglyphics are being neglected and people may lose interest in them.

MaxSem added a comment.Jun 9 2016, 7:21 AM

The whole Hierator thingie was rejected by the ops team. I'm not working on it anymore.

Phabricator_maintenance renamed this task from Switch WikiHiero to Hierator (tracking) to Switch WikiHiero to Hierator.Aug 13 2016, 9:34 PM