Brion Vibber wrote:
On 10/14/09 10:30 AM, Platonides wrote:
Expand CodeReview to handle feature requests and promote when people get enough supports? That would replicate the move in which, first bureucrats, then stewards were created.
Throwing in a huge number of committers at once is problematic as well since that means more time is going to be spent in post-commit review; new committers generally need some time to really ramp up.
Pre-commit review -- eg checking then committing patches -- takes longer, but is safer. It's a balance that needs to be struck and yeah, it's tricky.
Ideally we'd have a much faster, cleaner pre-commit review pipeline and keep the number of general core committers relatively small. (We wouldn't have nearly as many committers as we do -- over 100! -- if patch review were consistent.)
For contributing extensions, I think we could head towards having hundreds of committers, but I think we need to tighten up the security a bit, so that we can add lots of new committers without so much anxiety.
For instance, with a few minutes of research, I found a way that allows anyone with sillyshell access to destroy the whole repository. Seeing as we don't have any regular backup for it, that should probably be considered a bad thing.
Wikimedia has finally stopped checking out the entire extensions directory and exposing it to the web, but there might be other sites out there still doing the same insecure practice. It may make sense to split off an "extensions-contrib" directory where unreviewed extensions can be put, with less chance of jeopardising the security of servers.
Then there's the issue of commits to sensitive directories like the release branches and wmf-deployment. "Please don't" hasn't really proven to be scalable, because various people think it doesn't apply to them for various reasons, or were never told the policy in the first place. We don't have solid procedures in place that would protect us from server compromise by a disguised insecure commit to a branch.
In the short term, I propose to do the following: * Fix the login system * Implement three levels of access control using authz: * Extensions only (hundreds of users) * Core (~50 users) * Sensitive branches (~5 users)
-- Tim Starling