@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 <phoenixoverr...@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....@gmail.com> wrote:
> 
>> On Mon, 28 Jul 2014 22:59:40 +0200, John <phoenixoverr...@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

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to