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
