On Wed, Feb 8, 2012 at 12:17 PM, Rob Lanphier <robla(a)wikimedia.org> wrote:
After that it means, in theory, that trunk will be
open for
post-deploy commits. However, we *cannot* let the same backlog back
up that we did before, and there's no way we can keep up with
everything we need to do for deployment (last minute bugfixes,
addressing fixmes regardless of committer) while at the same time
dealing with a flood of new commits.
A big problem with our current post-commit review regime is that it is
exactly these times that really regrettable changes can and probably
do get made. Many refactoring exercises happen without much
discussion on the mailing list. The code doesn't get reviewed, and
then it gets entangled with a lot of other important code to the point
that we're forced to forge ahead with a suboptimal refactoring
decision.
This is one of the reasons I've been hoping we'd move to a more pre-commit
review model. Especially for big refactorings and cleanups that have
limited immediate value, we tend to get a lot of breakages a not a lot of
interest in fully reviewing them (eg actually checking all the code paths
to make sure they really work).
To a certain degree, I'd actually consider it desirable to have a permanent
'slush' to the extent that destabilizing work should *always* be talked out
a bit and tested before it lands on trunk/head/master.
If we're not ready to go fully git the instant we branch 1.19, we may wish
to consider applying more formal review to things proposed to go into trunk
on SVN. This may be simpler than attempting to synchronize SVN and git via
post-SVN-pre-git reviews...
-- brion