On Thu, Oct 15, 2009 at 3:40 AM, Tim Starling <tstarling(a)wikimedia.org> wrote:
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!