> Would it even be possible to deploy many MW extensions that are in
different top-level directories in one git repo without pulling
subdirectories from the repo individually?
Yes, you can get the whole repo in one go. So it'd be easier to get the extensions, although this really is just a very minor advantage.
> Won't there be inconveniences with automated testing if some extensions are not compatible with SMW changes (yet)?
I suspect not much, and it's probably cancelled out by the convenience of having them together when you actually want to test compatibility. But before we worry to much about this, let's first write some actual tests? :D
Just to be certain there is no confusion: I'm proposing on having all these extensions in a single git repo, and not have primary or secondary copies in random other repos.
> Who will be able to approve (or even self-approve) code in gerrit? Could
I commit to every extension without review then? Can others do the same
Since the gerrit rights are rep repo (at least AFAIK), there would be no distinction between SMW and the bundled extensions. I suggest to be liberal with (non-self-approve) merge rights and hand them out to anyone who requests them unless there is good reason not do. If they break stuff, the rights can always be revoked. And even while this would be liberal (definitly more so then what we have now), I'd be more restricted then what we had just a few months ago on SVN, where anyone with extension commit access could push stuff directly into SMW.
> I do not see the advantage of having SMW
> extensions maintained outside the normal MW git repo
Me neither. Did not suggest using an alternate repo.
> by installing from this repo the user would not be done, i.e. they would still need to manually get e.g. Validator.
Please read previous mails - I replied to this twice already.
> To simplify deployment and ensure compatibility: What about setting up a PEAR server?
This tackles a subset of the problems my proposal covers and comes from a completely different angle. Having such a things would be great, I even did a GSoC project towards it in 2010, but it's very much non-trivial to get it right.
> They already are in one repo, aren't they?
No. Each extension is in it's own git repo.
> Also, moving code from one extension to another is probably not the
> most common thing to do.
I know of quite some code that got moved around. Sometimes you start writing a feature somewhere and then want to split it of in it's own extension. Or you have an experimental extension that stabilizes and can then just be added as a feature in another one. But yes, it's not something you do every day. I am consciously avoiding doing it now since the code is in different repo's, as moving stuff would appear as code magically disappearing from one repo and appearing in another, without any links or version history between the two.
>> * Easier to track what others are doing (and having more visibility yourself)
> How so?
Can you give me a list of all changes that got pushed to any SMW or Semantic* repo recently? Can you give me a list of all changes pending review on gerrit? Can you give me a list of all branches?
None of those you can trivially do for multiple repos, they'd all involve writing some script that does various queries to gerrit. All of those you can trivially do for a single git repo.
Jeroen De Dauw
Don't panic. Don't be evil.