On Sun, Jul 31, 2011 at 3:46 AM, K. Peachey <p858snake(a)gmail.com> wrote:
1. 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