[Twisted-Python] major changes, release engineering, and learning cost

[Laurens Van Houtven]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20100526/1badc042/attachment.html>