On Wed, Feb 8, 2012 at 12:17 PM, Rob Lanphier <[email protected]> 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
