@John: Extensions are git repositories. Moving it to an extension involves moving them in
their own repo, like any other extension. I guess you're mostly concerned about it
being repositories not under mediawiki/extensions, because it'll be a repository
I'm inclined to agree. 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?
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
We have an mediawiki/extensions.git meta repository. To avoid conflicts with MediaWiki
core's extensions directory (which, albeit being almost empty, will still conflict in
unproductive ways when working with wmf branches), 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
That's a one time setup quite a few developers have already from what I understand
(Reedy, Chad and Roan all recommended it to me originally, not sure who had it first) and
from then on you just git-clone <path> or git-submodule-update--init <path>
any extension you run into when working in different projects, and can add a require_once
and it all just works.
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. And unless we
introduce a separate core skins path / external skins path variable, you can't really
set one without breaking the other.
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. 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.
On 28 Jul 2014, at 23:02, John <phoenixoverride(a)gmail.com> wrote:
I use a standard git checkout. Moving these to their
own separate location
is going to be a pain in the ass. If the skins are moved to the existing
extension system it causes far fewer problems and does not introduce
additional steps in upgrading/maintaining a site. When we start having sub
repos and forking left and right it gets ugly. We already have an existing
framework for adding modules to mediawiki (Extensions) let's use that vs
re-inventing the wheel.
On Monday, July 28, 2014, Bartosz Dziewoński <matma.rex(a)gmail.com> wrote:
On Mon, 28 Jul 2014 22:59:40 +0200, John
Why not just move them to an extension? moving them to their own repo begs
for a headaches
I don't understand the problem you see here nor the solution you're
Wikitech-l mailing list
Wikitech-l mailing list