On Thu, Oct 15, 2009 at 3:40 AM, Tim Starling tstarling@wikimedia.org wrote:
Proposed authz file at:
This seems to say that only the release group can backport things to branches. Does it make more sense to allow core to backport to branches, but require release to tag them? I have some commits to branches that I think were legitimate, personally. :)
The @core group there is just all 76 people who have committed to /trunk/phase3 in the last 12 months. It may need some refinement.
I think it's okay to keep it at that level. Narrowing it down would get rid of useful contributions, unless people are actually going to start reviewing Bugzilla patches. There's currently no way to reliably get your patches reviewed except committing it and forcing review by whoever wants to deploy. (And even that doesn't always work for large changes.)
I'm not actually sure what problem is being solved by restricting commits to core, though. If someone can commit a backdoor without anyone noticing, then they could almost as easily get one committed from a Bugzilla patch without anyone noticing. Except that no one looks at Bugzilla patches, but in that case the argument becomes "less changes means less security risk", which is throwing out the baby with the bathwater. Extensions authors might have occasion to adjust core code occasionally; that's one of the advantages of being able to commit your extension to Wikimedia SVN.
Restricting commits to wmf-deployment and tags (and maybe branches) makes sense, certainly. But I don't see the point in an enforced extensions/core distinction. Especially if extensions used on Wikimedia are counted as extensions and not core!