On Tue, Oct 4, 2011 at 4:29 AM, Olivier Beaton <olivier.beaton(a)gmail.com>wrote;wrote:
I'm going to nip this one in the bud right away,
and given that core
and extension SVN access is already separate already, I already know
we're making use of it. In your SVN auth file on the server:
[/mediawiki/trunk/extensions/SomeExtension]
username = rw
[/mediawiki/tags/extensions/SomeExtension]
username = rw
[/mediawiki/branches/extensions/SomeExtension]
username = rw
Branched extensions are a bit differently handled, but as we're about to see
most of the time I think we can just skip worrying about them entirely. :)
I had a good talk with Olivier on IRC, and I think we understand a bit bit
better where we're coming from.
The big thing is to make sure that people feel like they're being fairly
communicated with.
I think we do have an available spot between "full extensions read/write
access" and "host your files elsewhere for now" -- and that "go ahead
and
commit to your extension directory X" spot is a place we want to be to
attract and retain newbie developers.
(I should say, newbie members of the developer community! They may be old
hands we've just never interacted with before because they've been MediaWiki
*admins* and *users* out of our sight.)
The git stuff should place us squarely there: it should be trivial for
people to set up their own repositories to commit to that share our
infrastructure, with a little less work to do to migrate things into the
main community-maintained repositories.
In the meantime though we're still working in SVN; people who need SVN
commit access to get stuff done still need it, and we're still accepting
general requests, so it's good to make sure that people know what to expect
from us when they ask.
I suspect the primary case that would be nice to handle goes something like
this:
Bob has written a MediaWiki extension BobsAwesomeExt that he'd like to share
with others. He wants it to be in MediaWiki's source control system for
archival purposes, making downloads easy, and to help it get future
maintenance (localization, security fixes, compatibility fixes) even if Bob
ends up wandering off later. If Bob ends up staying (which would be great!)
then this gives him an account to start with and a visible stream in
CodeReview to start interacting with other developers.
In SVN land, Bob mainly needs to be able to commit into
trunk/extensions/BobsAwesomeExt. In theory people could maintain version
branches for extensions but in practice.... almost nobody does except for
core contributors merging fixes.... so we don't really have to worry about
permissions on those branch or tag directories.
So it would probably not be too terrible a burden for us to stick some more
one-off extensions in in the short term, just with an eye for making sure
that we're capturing and keeping the code and developers who are already
knocking on the door.
What we *do* want to avoid is ending up with a full-blown
complicated-permissions setup on the current SVN; but I don't think we'll be
forced into slippery-slope territory by adding a few single-directory
single-user permission grants.
(In future git land, giving Bob full read-write access to the BobsAwesomeExt
main repository will let him do all the branch maintenance he wants, so this
would not be a permanent restriction.)
Now we'll still want to make sure we can consistently manage permissions on
the git repos, but we'll want to make sure we know how all that works before
speccing out that setup. :)
If you're not in a hurry but would like to prepare for moving an extension
into our git space when it's ready:
* stick your code on a public git host like github or gitorious
* you'll be able to push it -- with all history -- into MediaWiki's hosted
git space later
-- brion