On 11-10-04 04:29 AM, Olivier Beaton 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
Done. Right now I imagine for extension only access there is just 3 entries like the above, but for the whole extensions directory (I'm guessing) and one for the whole repo.
Ok. Let's see. Firstly most extensions don't use tags so we can omit that, but we don't use /branches/extensions that way, it's more like /mediawiki/branches/REL#_##/extensions/SomeExtension. We'll need an extra line for each release, so say an extension was committed in 1.15 we'll need 4 entries now, and another when we branch 1.19. Ok, pretending that we only give one user access to an extension, that all extensions were committed in 1.15, and none use tags. We have 586 extensions inside /trunk/extensions/ currently. Doing the math, 586 (extension count) * 5 (entries per extension; trunk + 4 REL branches) * 2 (lines per entry) = 5860...
So are you trying to seriously argue that ops should have to maintain 5860+ lines of config and add an extra 1172+ for every release we make, just to restrict extension authors into their own extensions?
You are sane, right?
And what review? You're not looking at code quality here, if they have a working extension that they are releasing, do you really want them pasting it onto the page on mw.org? I keep hearing people saying they want to check all those in. Where's the review there? At least with a checkin people have the opportunity to give them real feedback instead of being ignored and stagnate into obsoleteness on mw.org.
And really I don't think you can really comit to maintaining every extension every person makes forever. Let's be realistic here, it's their extension, they will maintain it, and if not and it breaks after a long period of time, you archive it with no activity somewhere in /branches/archives or another plan.
There's a beautiful tool we have called 'grep'. Plenty of the breaking changes we make in core are ones we make on purpose to improve the system and are ones that it's rather simple to find extensions using the old interface by doing a quick grep. Then we go through the ones using the old problematic interface, change them to use the new code, then commit. Tbh, if we threw unit testing into extensions we could make batch changes and ensure extension compatibility with new versions of MW even more confidently.
Plenty of extensions are rather simple. Plenty already work when they commit. Plenty will continue working until a minor interface change means they need a tweak to be made to them. And plenty of those tweaks can be made en-masse. Along those lines we have plenty of extensions that can be 'maintained' indefinitely simply by sitting in trunk with no specific maintainer getting automatic i18n updates and small tweaks when an interface changes.
The idea that only the extension's creator / maintainer would maintain an extension is flawed in the first place. People like to use extensions and people notice when they break, usually as the result of minor core changes. Hence, even if an extension no longer has an actual maintainer it may have people who have been using it. And all it takes to fix most issues is one of them to poke someone to make a minor tweak to the extension. A number of extensions may even be used by people who can develop but wouldn't bother taking the task of maintaining the extension. When an extension breaks generally one of them might happen to notice it breaking, fix it, and commit that fix into trunk so that they can use the functioning extension inside their own wiki.
What I'm saying is requesting access + having a finished extension should mean someone can immediately just add them access.
;) and what I'm saying in our planned git workflow you probably won't even need that much to get access.
You're right this means one request per extension, but after 2 you should be asking yourself "okay this person is contributing a lot to the community, maybe we can give them access to the whole ext dir?" and actually review them.
On Tue, Oct 4, 2011 at 3:35 AM, Daniel Friesen lists@nadir-seen-fire.com wrote:
On 11-10-03 07:08 PM, Olivier Beaton wrote:
#2 Extension access? Has a working extension attached to submission (has some .php files in it, no need for a code review here, the community will handle that) . Granted. Create their account, and give them access to _only_ their extension directory.
SVN Doesn't work that way. We can apply limited restrictions like making the wmf branch and trunk only accessible by specific groups. But we can't create efficiently (I don't even know if it's possible at all) create a separate right for each and every extension and give new committers only access to their own extension. So anyone that gets commit implicitly has the ability to screw up any extension or tool other than phase3 or the wmf branch. Besides, such a pattern would suddenly mean that instead of an extension author going through review once, they'd have to go through review for each new extension they make so that we can add the new directory and right.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]