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(a)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]