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" <mar...@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 <ya...@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
>
------------------------------------------------------------------------------
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
