@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 either way.
@Bartosz:
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 important benefits.
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 ../extensions instead.
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.
— Krinkle
On 28 Jul 2014, at 23:02, John phoenixoverride@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@gmail.com wrote:
On Mon, 28 Jul 2014 22:59:40 +0200, John phoenixoverride@gmail.com wrote:
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 proposing. Elaborate?
-- Matma Rex
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l