On Sun, Jul 31, 2011 at 3:46 AM, K. Peachey p858snake@gmail.com wrote:
- Write up a proposal somewhere (Eg: in your userspace on wiki then
share the link around or post it to the mailing list) 2. Apply for commit access (link to the proposal/patches you have done etc etc, we do have the ability to give access to certain sections of the SVN such as branches without allowing committing to to the main trunk of mediawiki (/phase3/))
Although some people may recommend doing major changes off site (eg: github), I highly recommend against this since most of our devs don't want to have to go offsite to review code changes unless you do it via a Git to SVN gateway system/setup (eg: Brion does this for some work).
I usually do that for self-contained pieces like a new extension -- this can be built in isolation (but in a way that you can share for ongoing review and testing), then pushed over to SVN when it's ready.
It can be a little trickier to do for existing core code that way. (Extensions are also easier to develop straight in SVN, since new ones don't have to be backwards-compatible! It's ok to check it in and have it a little flaky still if it's not yet completed or used.)
Generally speaking the best thing is to start tossing the idea around here on the list (& write up a page on www.mediawiki.org/wiki/RFC); if there's a relevant bugzilla entry, start posting patches there when code's ready to be tested / reviewed. We're trying to find ways to make the communication -> review -> response feedback look more reliable, so feel free to speak up if you're not getting clear directions!
For big changes, usually there's an advantage to splitting it up into smaller pieces. You can then do various parts of the change relatively independently; changing one thing at a time. This can make the code easier to follow for reviewers, but even more importantly makes each change easier to understand *and test*... and in many cases, self-contained stages mean that we can make the actual commits incrementally without breaking backwards-compatbility.
-- brion