Hey,
> 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 for
SMW?
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.
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
