On Wed, Feb 8, 2012 at 4:40 AM, Petr Bena <benapetr(a)gmail.com> wrote: Sam will be doing it soon. 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. In addition to building up a large review backlog, we also find ourselves chasing pockets of breakage due in part to incomplete refactoring and backwards-incompatibility breakages. We're migrating to Git very soon after this release. It would really suck to have a huge pile of unreviewed commits going into trunk. So, I'm going to suggest a Git migration strategy that will avoid having a monsterous backlog. Instead of cutting over trunk at the very latest revision, we cut over at the latest revision that is fully reviewed and ok. Everything before the 1.19 branch point would be grandfathered in, but everything after would need to be reviewed and ok. So, for example, if r111000 is the branch point, and r111000-r111020 are reviewed, but r111021 is a huge omnibus change that sits unreviewed or fixme'd, then r111020 would be the branch point, even if r111022-r120000 are fully reviewed. That's hopefully an extreme example, but the goal is to make sure that trunk is always fully reviewed. What would happen to everything after the branch point is tbd. I haven't talked to Chad about this, but I think it's conceivable that we can import the remainder of commits into a branch that we can cherrypick. The dynamic that this will create is that it will motivate more peer-to-peer scrutiny of code, rather than waiting for one of the reviewers to play bad cop. Until we agree on this strategy or some other strategy that everyone agrees is workable, we'll need to keep the code slush in place. Thanks Rob