Aryeh Gregor wrote:
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. :)
Yes, I know you made commits to branches, several people did.
tstarling@shimmer:~/src/mediawiki/branches/REL1_15/phase3$ svn log --stop-on-copy --xml `mi` | xmlstarlet sel -t -m //author -v . -n | sort | uniq -c | sort -rn 31 tstarling 3 siebrand 2 simetrical 2 ialex 1 shinjiman 1 demon 1 catrope 1 brion
I had to review them all to try to work out why the developer thought each patch was important enough to be backported, despite in most cases the lack of a meaningful commit message. It would have been much easier if everyone could have listed their backports on the release tracking bug:
https://bugzilla.wikimedia.org/show_bug.cgi?id=18629
Or alternatively, tagged the revisions on CodeReview and added a comment.
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.)
By that logic, keeping it at that level would lose useful contributions too, since I could have used two years instead of one for the time period scanned and made a larger list.
But I don't think your logic is correct, because I think active committers are more likely to be able to interact with the core developer community, contacting someone by IRC or email to get their patch committed.
And it's not fair to say that nobody has been reviewing patches on Bugzilla. Look at the history of phase3/CREDITS. Demon especially has been doing some good work in this area.
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!
The point is to encourage interaction between core and extension developers and to distribute the daunting task of code review.
The problem is the difficulty of keeping the core at an appropriate level of quality for its high visibility. The proposed solution is to encourage active core developers to have a sense of responsibility for core quality, by positioning them in a role which services the wider extension developer community.
In the current structure, the risk we run when we approve commit access is that the developer will start committing lots of clueless revisions to phase3. Such people demand detailed review and mentoring. In the current structure, we can only deal with a few such people at a time, otherwise quality suffers.
The time invested by senior developers in that process is large enough that it makes sense to restrict commit access to only the people who are talented and serious enough to stick around for long enough that our investment in mentoring will pay off. By encoding the core/extensions split as an enforced policy, we can remove that requirement for extension developers, thus expediting their request for commit access.
-- Tim Starling