Hi,

I still think that this is a bad idea, due to the fact that it sets up a two-tier system of extensions, with somewhat arbitrary criteria over what gets included. The only extension that I think can be included without any controversy or complications is Semantic Result Formats. Any other extension either has additional requirements, or has spinoff extensions, or has "competitors", or is not widely in use, etc.

I admit, though, that I don't really see the advantage of putting more than one extension in the same repository in the first place, if it doesn't make download easier and it doesn't enforce any sort of compatibility. Whatever the advantage is, is it enough to outweigh the negatives?

-Yaron

On Jul 17, 2012 7:15 AM, "Markus Krötzsch" <markus@semantic-mediawiki.org> wrote:
Hi,

as I understand Jeroen, this is mainly a proposal about code
maintenance, not about deployment. Somebody who pulls the whole repo
will have the code for all extensions that are in there, but that does
not mean that they are all enabled (or even mutually compatible).

It seems to me that a joint repository would not work very different for
people who run wikis with code from git (development or not). You still
need many individual pull commands, since you need many parallel
directories that are not in a joint super-directory that is in the
SMW-repository (the MW extension directory is part of MW's repository).
I suppose that you cannot pull many extension directories into
./extensions with one git command in this case. So what people would do
is still to check out each extension that they want to use individually.

Similarly, we would not automatically have a different distribution than
we have now. Maybe work on SemanticBundle would be simplified by a joint
repo, but the SMW package will look as before. So there is no change for
the final user.

If this is all true, the proposal is mainly a decision about simplifying
some of our development processes. I would support this.

A possible problem that I can see is with automated testing: if some of
the other extensions break due to some SMW change, then the maintainers
of these extensions need to fix it; they may not do this, or at least
not do this immediately. We cannot quickly move extensions out of the
joint repo, so this might be a nuisance once automated tests are enabled
on pushs (SMW changes will not get auto-verified). Is that an issue?

Markus


On 16/07/12 23:48, Daniel Schuba wrote:
> I think, before bundeling any extensions, there could be something like a compatibility check. Wordpress for example has something like this, and even allows to install plugins directly. So I think something like a compatibility and dependency check would be better. But on mediawiki side, not especially for SMW.
>
> Am 17.07.2012 um 00:18 schrieb Yaron Koren <yaron@wikiworks.com>:
>
>> Hi Jeroen,
>>
>> I don't think this is a good idea as you've described it. It would certainly increase convenience, for all the reasons you mention. But on the other hand, it would automatically set up a "two-class system" for extensions: those that are grouped in with Semantic MediaWiki, and those that aren't. In some cases, this wouldn't be controversial: I think everyone would agree that Semantic Result Formats is the right extension to use if you want to display semantic data in charts, calendars and the like, and that Semantic Maps is the right extension to use if you want to display it in map form. However, there are various cases where it's not so obvious: for instance, Semantic Watchlist provides notifications about changes to SMW data, but there are two other extensions that, at least in theory, can be used for the same thing. And the Semantic Image Input extension provides a useful input for Semantic Forms, but there are various other extensions that provide just one or two form input typ
es: what are the criteria for deciding which of them get included and which don't?
>>
>> There are some technical issues as well: you didn't include the Validator and Maps extensions in that list, even though they're required by SMW and Semantic Maps extension, respectively; presumably because there are people who would want to install those without installing SMW. But at that point, the whole thing starts to feel a little like a hack.
>>
>> Let me make a counter-suggestion, then: the Semantic Bundle package already does essentially the same thing, of holding a curated group of extensions. Is it possible to make a Git repository for Semantic Bundle, that just holds symbolic links (or whatever the term is) to all of its extensions, in a way that can be downloaded all at once, either via Git or as a tar file? That's essentially what happens with Semantic Bundle already, although the SVN part of it doesn't work that well. Maybe with Git it can function better, given Git's greater flexibility.
>>
>> Tied in with that, maybe it makes sense to upgrade Semantic Bundle to a recommended download solution for SMW, so that, for instance, instructions on how to get it are right on the SMW download page, instead of on a linked page. That seems like a good idea to me, though others might disagree.
>>
>> -Yaron
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Semediawiki-devel mailing list
>> Semediawiki-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>
>>
>> _______________________________________________
>> Semediawiki-devel mailing list
>> Semediawiki-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel