I've said something in #twisted but I hadn't read this reply yet, so for sake of saving this for posterity, I agree with jml here. I think we're mostly being bitten because of a lack of software tools, in the form of svn and trac. Disclaimer: I really dislike svn since I never figured out how Combinator works. I really dislike trac.
So, for the rest of this e-mail, let's pretend we're implementing a big new feature since that's the thing I tried to do to some extent. Major stuff could be a blueprint on Launchpad. Blueprints match a branch for the "big feature". So, we have the Twisted blueprint quantum-transmogrification and a branch lp:~lvh/twisted/quantum-transmogrification. >From that branch I create a bunch of branches of review units (if it turns out it's too big, I just branch again for a new review unit). So, I want to do something with entanglement: lp:~lvh/twisted/quantum-transmogrification-entanglement, and it's good, so someone reviews and sends it back. lp's merge proposals let you do the code review in arbitrarily small chunks. So if the thing I do next is lp:~lvh/twisted/quantum-transmogrification-ftl-travel, and it turns out FTL travel is really really hard so I need two smaller branches lp:~lvh/twisted/quantum-transmogrification-tunnels and lp:~lvh/twisted/quantum-transmogrification-ansible. Both are good, so they get put back into ~lvh/twisted/quantum-transmogrification-ftl-travel. Each review would verify that all children (if any) have also been reviewed. So, the final review is pretty small, as suggested :-) This does not limit a developer's freedom to branch at will, because code review is opt-in (merge proposal), not opt-out. If you don't do it, that code in that branch isn't covered by a previous review, and must be reviewed later. How exactly code review coverage would work is somewhat of an open question and it's the obvious failure in this system. We use it in production and it turns out to not be a problem, because people always end up doing two things: 1) always branch at least once from the first branch off trunk (so branch off lp:~lvh/twisted/quantum-transmogrification). Net result: lp:~lvh/twisted/quantum-transmogrification only introduces code in the form of merges. 2) always do code review on branches being merged into your first branch off trunk (so everything merged into lp:~lvh/twisted/quantum-transmogrification has to be reviewed already) Note that our merges into trunk are automagic. If it's merged into a direct branch off of trunk and it satisfies some qualities (such as full test coverage :)), it gets put into trunk, and that gets pushed to production servers. No human interaction. Scary at first, but then you realize humans were already involved in the QC process extensively at every point -- doing it this way just makes them take testing more seriously :) I think a bug would be similar except the root would not be a blueprint but a bug. Laurens
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
