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