Aryeh Gregor wrote:
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. :)
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