On Wed, Feb 8, 2012 at 4:40 AM, Petr Bena <benapetr(a)gmail.com> wrote:
> Hi, is there any update on branching? Thank you
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