On 10/03/2011 05:18 PM, Brion Vibber wrote:
On Mon, Oct 3, 2011 at 6:30 AM, Yaron Koren yaron@wikiworks.com wrote:
I think developer accounts on the Wikimedia SVN repository should be easier to get. I say this because a consultant of ours at WikiWorks, Ike Hecht, asked for a developer account last week and was rejected. He created his first major MediaWiki extension, Ad Manager, recently, which I added to the repository a few weeks ago - you can see it here:
[snip]
Specifically as regards stand-alone extensions we've generally been much more liberal than for core -- perhaps Ike forgot to mention that this is for maintenance of an extension that's already been committed and that several people are vouching for him and his code?
He mentioned the ad manager extension, and linked to it, but did not mention that others were vouching for him.
Generally speaking...
TL;DR summary: we also want to make it easier to get involved; this is a work in progress! :)
We're currently in a sort of no-mans-land in trying to make sure our policies are reasonably responsive and consistent, knowing that we're sitting just ahead of a planned migration from SVN to Git which will change the permissions landscape.
In a Git world, it should become a *lot* easier to fully participate in the development ecosystem without having to get an account manually approved and created.
Part of what us coders need about having a SVN account now is simply that without direct checkin ability, you can't, well, check anything in. :) You otherwise have to wait on other people to look at your code before it even gets into the system, and your commit won't even have your name on it when it gets there. :(
In git-land though, we can basically eliminate most of the distinction between a "submitted patch" (floating around from Bugzilla, mailing list, or IRC) and something that's been committed-but-not-yet-reviewed (the scary world of CodeReview, where bad code can live on breaking other things until people figure out how to fix it months later ;).
Commits will be fully labeled with the names of their creators, whether they got committed straight to core by Tim Starling himself or whether they came in as a pull request from someone who's forwarding work from someone we've never seen before.
Review and fixes can happen on a custom branch -- fully versioned -- and be merged in to mainline after further commits are made to tweak them.
Being able to maintain extensions as standalone git repositories will further reduce the difficulty of getting in: setting yourself up with a git account and creating repos for your extensions will become entirely self-serve (no need to "ask" for every individual git permission).
We should end up in a better position to do both totally self-serve and semi-curated work (eg, shared maintenance of translations and security updates).
-- brion
I am looking forward to this. But in the meantime, let's make sure we clarify our ruleset.