Oh boy. That was a bit uncalled for there, I'll try to reply to the parts that were civil.
On Tue, Oct 4, 2011 at 9:51 AM, Daniel Friesen lists@nadir-seen-fire.com wrote:
Ok. Let's see. Firstly most extensions don't use tags so we can omit that,
Why not? Extensions have versions, why shouldn't they use tags?
but we don't use /branches/extensions that way, it's more like /mediawiki/branches/REL#_##/extensions/SomeExtension. We'll need an
Ah, I wasn't aware of that. That changes thing a little, as you so nicely pointed out. Clearly from my example I wasn't proposing adding 5000 lines to a config file. Clearly. Why you insinuate that is beyond me. Like my mention of tags, I was assuming extension authors might want to write branches for their code. I know I've done that a few times when I wanted to try out bigger new ideas or directions. The whole copy every extension at the point of branching as far as I understand it, is so that you can always get the extension at the version that existed during that release (and hopefully works and has less bugs).
There's a beautiful tool we have called 'grep'. Plenty of the breaking
That's fine for small updates and will undoubtedly keeps things running for awhile, but I don't see that working out long term for any reasonably complex extension. But I don't think I have to argue this point, because either way you look at it, you want that code in svn. You don't want to be sending people away, you want them checking it into svn so you can do those small mass updates.
My ideas about access restrictions is meant to address this concern with giving people svn access. It's so that you can give more people access, more quickly, with less overhead (code review).
The idea that only the extension's creator / maintainer would maintain an extension is flawed in the first place. People like to use extensions
Right, you want other people to take over maintaining an extension, especially popular ones, if it gets abandoned. This is hard if you don't get people to check in their extensions, for which you need to give them access first and that's what this is all about.
;) and what I'm saying in our planned git workflow you probably won't even need that much to get access.
As I understand git (which is not very much), it will solve some of these problems. Here's a workflow:
a) I'm coding my extension on my machine with my own repo for my extension, I'm ready to do a release, I send it to the mw repo for merging into the extensions branch b) Who approves the merging into mw.org? Does it have to pass a code review just like core changes? Who will have the rights to do code reviews and say "ok it's ready now"?
I'm all for code reviews, if there was a place I could submit my extensions for review, I'd do it in a heartbeat, I'm new to mw.org and I'd rather find out now if I'm doing things wrong or could do them better, than in a few months maybe if someone happens to look at it and feel I'm approachable enough.
In the end though if you make that code-review a show stopper you may end up splitting the community a lot, instead of authors helping authors it will be some authors gate keeping and blocking code from others. If I make a feature or improvement to my extension that I've coded and whoever is reviewing doesn't think it needs the feature... really?
MW.org is offering, or attempting to offer a really unique and great service. Versioning, code reviews, and distribution. Even "We'll help you keep it up to date with core api changes!".
Sounds fantastic, but if you can't get people to check in their code, and be able to have those checkins happen in a timely basis, people won't use the service, and just see it as elitist instead of the great thing it should be.
In the short term my suggestion stands. don't give them access to branches/relX/extensions. That's not what I said. If you'd rather skip branches and tags altogether even that would be okay. Just give them access to trunk/phase3/extensions -- once they prove themselves, then extend that to all extensions and the rel branches extensions folders like you currently do.
- Olivier