On Tue, 29 Jul 2014 13:00:37 +0200, Krinkle <krinklemail(a)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
--
Matma Rex