On Tue, Oct 4, 2011 at 4:29 AM, Olivier Beaton olivier.beaton@gmail.comwrote:
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