On Tue, 29 Jul 2014 13:00:37 +0200, Krinkle krinklemail@gmail.com wrote:
(…) I personally do not see any use in having mediawiki/skins/* in Gerrit as separate structure for repositories that are extensions in every way. An extension can provide hooks, messages, config variables, special pages, skins, api modules, resource modules and more. A skin repo would typically provide at least three of these (messages, skin, resource modules) and possibly hooks and config variables as well. What's the point in having a separate scheme for repos that provide some arbitrary subset of these features?
In the Glorious Future, there might come a day when skins will no longer need to provide any PHP code; they'd just define some configuration, HTML templates and CSS+JS. One can dream, eh?
mediawiki/skins/* is already the de-facto accepted hierarchy for skins in Gerrit, with about 20 repositories there (and most of them indeed functional) [1]; I am not aware of any skins in mediawiki/extensions/ other than Nostalgia (which has been migrated to skins/ too).
The naming has been discussed on this list in the past, and the result is summarized at [2].
[1] https://gerrit.wikimedia.org/r/#/admin/projects/?filter=mediawiki%252Fskins%... [2] http://www.gossamer-threads.com/lists/wiki/wikitech/465428#465428
But more important than the naming scheme in Gerrit (which I could care less about) is the local development workflow which affects developer productivity and understandability of our eco system. Let's aim to keep be as simple as possible without compromising on important benefits.
I don't think using skins/ in this way is as problematic as you're making it seem:
We have an mediawiki/extensions.git meta repository. To avoid conflicts with MediaWiki core's extensions directory (…) I always advocate people set up an extensions directory on their disk elsewhere (e.g. next to mediawiki-core, not inside), either as the meta repo clone or as your own container directory with git clones of individual extensions inside of it. Then simply configure $wgExtensionAssetsPath to point at localhost/git/extensions or whatever and require_once in LocalSettings from ../extensions instead.
This is possible with skins in exactly the same way, but instead of $wgExtensionAssetsPath you configure $wgStylePath.
The 'common' directory might be a bit problematic here. I think we should just get rid of it once and for all and put the assets in resources/ where they belong.
This could be set up for skins as well, but it's tricky. Aside from having two systems then, it's still tricky. At least for a while to come (working with current wmf branches, and release branches) we can't guarantee skins/ to be empty. (…)
It is possible to get it right but it comes at the cost of several months / up to 2-3 years of inconvenience locally for everyone. (…)
There will be no 'two systems'. We're removing skins from core and moving them to separate repositories. That will be the only way from now on. With the exception of the aforementioned 'common' that we need to kill, the skins/ directory will be empty.
The transition period will of course require some additional care, but I don't see how it could take years. The WMF will need to care about it for a total of about two weeks while the deployments roll by (less if we backport the changes, which might be a lot easier with our submodules setup). The people who backport changes would have to deal with it for longer, were it not for the fact that the new way is backwards-compatible with older MediaWikis (set up the skins/ directory the way you described, and it should work back to MW 1.19 at least) and the fact that we rarely need to backport changes to skins anyway.
We haven't committed to this new structure yet, and instead of taking this opportunity to create a mess for years to come, I'd rather take this opportunity to get rid of the mess that is mediawiki/skins altogether and just fold it all back into extensions.
To get the ball rolling: What's the downside of going that route? We have quite a lot to gain in terms of simplicity and compatibility.
Breaking things can be good, but I haven't seen any short or long term benefits so far that would justify it.
I'm really not convinced how it creates more of a mess than what you propose. This structure is consistent with user expectations (of skin developers and sysadmins), already established practices in the MediaWiki community and other projects like CMS-es and forums (again, see [2] and earlier discussion). I think that is a big win.
[2] http://www.gossamer-threads.com/lists/wiki/wikitech/465428#465428