On 11-10-03 07:08 PM, Olivier Beaton wrote: > It seems pretty straight forward to me, > > #1 Core access? Keep existing review process in place, could take 6 > months, sorry. Patches that will never get committed for you! > #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.
> If you want to foster a more communal and helping extension community, > when it comes to do core access reviews, use a script to spit out > active people on svn, and if any of them only have access to their > extension directory, pro-actively have a short sentence or two about > if you should give them access to all extensions. If yes, let them > know the happy news, maybe they will do something with it (likely not, > even if they had it in the first place). Another metric might be if > they have a lot of tickets for other core extensions with patches > attached. > > They can't be that destructive in their own space, and if they have a > complete working extension, chances are people in the community will > start using it, and invariably come into irc complaining if the > quality is low, better to nip this one in the bud and get them into > the code review process early. Like all the people being so helpful to > me in IRC. I don't want to wait months to find out I've been doing > things all wrong. > > For extension access there isn't many reasons why you can't make them > an account on the spot and see how it goes, whoever is around and sees > it first (even Sumana). > > I haven't used git, but won't you need to decide what gets comitted in > git as well, no matter what they comit on their own HD? It will still > be 'get it moved into a extension branch on git, have your revisions > reviewed, get it into the extension distributor'. I see this applying > no matter which way you go. In git each extension, core, or other project is a separate repo. Because of that whatever model we use with git it's possible to efficiently let a user have access just to their extensions. So that model you describe where anyone can have access to their own restricted area, that's the potential git model, not reasonably possible with svn. Additionally the plan seams to be to use gerrit to a large degree. Apparently the plan is what Ryan calls a "gated trunk". For something like core when you push your commits in; Instead of the changes actually being applied right away the changesets are instead put into the repo but not applied to the master branch, and a new changeset shows up in the gerrit interface. At that point the change can be reviewed by other people, and will probably also be reviewed by scripts checking to see if the change breaks any tests. After a reviewer has okay'd a changeset gerrit merges that change into the main part of the repo. At least that's my understanding of how the gerrit setup works from my discussion with Ryan. I do need to bring up an e-mail about that. > Just my 2c to the pile, now banking a dollar. > - Olivier -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
