Hi Jeroen,
Ah, I was confused - your specific listing of extensions at the beginning
made me think that this was going to be a curated list of extensions, in
the manner of the Semantic Bundle. But if essentially any SMW-based
extension can get added, then I don't see what the big benefit is. It seems
very difficult to make sure that an arbitrary number of extensions can all
work together when it's time to do a release - at the very least, it would
take a lot of time and coordination. And even if you accomplish that, there
are still other extensions, like Validator and Maps, that would require
coordinating outside of the SMW repository.
Instead of a centralized solution, why not have a distributed approach,
where various repositories, like for Semantic Bundle and anything else, can
have symbolic links to the right version/tag/branch of each extension, so
that downloading that package will always get you a set of extensions that
work with another? (Is such a thing even possible in Git? I hope so, but I
have no idea.)
But perhaps I'm missing something in this whole thing.
-Yaron
On Wed, Jul 18, 2012 at 11:02 AM, Jeroen De Dauw <jeroended...@gmail.com>wrote:
> Hey,
>
>
> > as I understand Jeroen, this is mainly a proposal about code
> > maintenance, not about deployment.
>
> It's about both.
>
>
> > 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
>
> First of all I'd like to point out that MediaWiki itself already has this,
> and no one is complaining there,
> nor has it created any two-class system.
>
> The criteria would not be arbitrary - pretty much all code that developers
> want to put in there could go in,
> only when there are serious issues with it, it can't. If something ends up
> getting unmaintained or unstable,
> it would be appropriately marked as such, and only at a point where it
> starts causing problems somehow
> it would get thrown out. The people working on the code / maintaining it
> would decide on this, and any
> developer could join this process. It'd be pretty much the same as what we
> have now for code changes
> to SMW itself, but then on extension level.
>
> And in case of extensions, two competing extensions can actually both be
> in the repository, where
> two competing pieces of code obviously could not both go into SMW :)
>
>
> > 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
>
> How is this an issue? They are not in the same repo now and they would not
> be then. The workflow
> for including them would remain the same.
>
>
> Cheers
>
> --
> Jeroen De Dauw
> http://www.bn2vs.com
> Don't panic. Don't be evil.
> --
>
>
> ------------------------------------------------------------------------------
> 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
>
>
--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
------------------------------------------------------------------------------
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
