Thank you for all the comments! I've had a few busy days, sorry for only replying now. I'm going to try summarizing everything.
I have replied to a few tangenial messages separately. Many things have been said here (and in several disconnected threads), so I might have missed something – please remind us if you think I did :)
Table of contents: * Skin autodiscovery * Capitalization of skin names and their file/directory names * On 'skins/' vs 'extensions/' * Handling WMF deployment
----
First of all, something we all agree on: let's murder skin autodiscovery. I'll submit patches to emit deprecation warnings if a skin using it is found (to master and 1.23 LTS release), and another patch that will remove it entirely (intended for MW 1.24 or MW 1.25).
I will also convert the core skins not to use autodiscovery first. I'll keep them in 'skins/' for now, it'll be less disruptive in WMF environment and easy to change later if we decide to.
----
As for Daniel's concerns about capitalization differences (which are valid regardless of which directory we want to place the skins in), forcing everything to be lowercase is a solution, but one that I don't like very much. Keeping the status quo is also a solution, but clearly no one at all likes this one.
I'm going to name the three names we have 'skin file name' (same as skin directory name), 'skin name' (the one used in $wgValidSkins, saved in user preferences etc., used for site and user JS and CSS pages) and 'proper skin name' (localised one displayed on Special:Preferences).
Let me propose two more ways we could do this. (All of the back-compat concerns below don't apply to new skins, only existing ones that we'd want to retro-fit to the new way. We could also avoid them by not retro-fitting.)
* Instead of switching file name to lowercase, why not switch skin name to CamelCase? We'd have a maintenance script to update user preferences in the database, and a little back-compat layer to allow skins to define non-canonical names they want to respond to (for site admins who can't run the maintenance script).
This will, however, break back-compat for JS user scripts (that implement different behavior per-skin), as well as very poorly written PHP-side code (which should have no reason to care about skins). This might be acceptable.
* Always compare skin names case-insensitively (which is easy if they're all-ASCII), in 'useskin', in database user preferences data, everywhere – and use CamelCased names in "user-visible" areas. We could keep the canonical skin names the way they are in existing skins for back-compat of user preferences, but site admins would be able to set $wgDefaultSkin = 'CologneBlue' even if the canonical skin name was 'cologneblue'.
As far as I can tell this will not break back-compat at all, and would let us move forward leaving very little tech debt behind.
* (Or maybe sidestep the issue, say that you can do this in whichever way and just keep the current way in existing skins – this would be lowercase everywhere for most, if not all. This would suck though. :) )
----
As for where to put the skins, which is what most people care about.
Reading the replies, most people who actually make skins seem to prefer the 'skins/' directory, and have provided some excellent reasoning for this (better than mine, thanks people!). I've been undecided myself, but right now I really feel this is the way we should go.
Excerpts:
On Tue, 20 May 2014 23:38:14 +0200, Tyler Romeo tylerromeo@gmail.com wrote:
I do agree with keeping skins in a separate directory than extensions. It implies a bit of control on our part concerning how skins need to be structured, whereas if they were extensions, we cannot place any requirements on the structure.
On Wed, 21 May 2014 00:06:57 +0200, Jack Phoenix jack@countervandalism.net wrote:
CamelCase is how we name things consisting of multiple words (i.e. BlueSky, DuskToDawn, HowTo, ...), so it's only reasonable to use CamelCase here too.
On Wed, 21 May 2014 20:10:40 +0200, Nick White nick.white@durham.ac.uk wrote:
the skins/ directory is a sensible place for skins, and the fact that they in practise aren't fundamentally different to extensions is largely irrelevant.
On Wed, 21 May 2014 22:38:00 +0200, Stephan Gambke s7eph4n@gmail.com wrote:
I agree that skins and extensions should be installed in the same way as much as possible. But I do not agree that this should go so far as to install them in the same directory. They are fundamentally different things - one concerns (ideally) the functionality of the wiki, the other (ideally) its presentation.
On Thu, 22 May 2014 01:31:57 +0200, Isarra Yos zhorishna@gmail.com wrote:
From a sysadmin standpoint, the extensions repository/directory is basically a horrible pit of extreme darkness full of many things that that you basically have no idea what they are because their names are completely unhelpful. This is kind of not good, and we do not want to make it worse, because unlike extension names, which sometimes are helpful, skin names basically NEVER give the slightest indication what they are. (…)
Whereas if we put them somewhere else, such as in 'skins', a place where people would probably expect to find skins, it is immediately clear what they are, both in the filesystem and in the settings files. (…)
----
However, WMF ops/core/platform people seem to prefer 'extensions/', because we've already worked out the process for extensions so it'd be nice not to have to do anything else for skins ;).
Given the arguments above and overwhelming support of people who actually do this stuff, I think that putting skins in 'extensions/' should really be a last-resort solution if everything else fails.
Are there any fundamental, insurmountable issues with having skins in 'skins/' in WMF production? Or is it just a matter of performing some boring, but simple changes to deployment scripts and processes (wrapping things in `foreach ( ['skins', 'extensions'] as $dir )` etc.)? If it's just that, I'd be more than willing to help applying them (I generally have some idea on how this stuff works and where to find it, but I'd probably need help and of course code reviews).
So, I'm proposing an experiment: We can evaluate this almost painlessly by converting the current Nostalgia extension-skin to a skin in my proposed format, deploying it on nostalgia.wikimedia.org (after doing whatever changes are necessary to deployment things first) and seeing what happens. This should not affect the rest of the cluster, and even catastrophic failures would have a very tiny "surface area". If it turns out that this is really not going to work, we can always revert all changes and stick with stuffing skins in 'extensions/' instead.
Tim, Brion, Dan: How does this look to you?
----
Thank you for all the comments again!