[IPython-dev] Tweaking the IPython development workflow

[Brian Granger]

> One could say the model could work better - last checkin to trunk was
> done 2 months ago (because people are not reviewing). Perhaps a
> "retroactive review" could work better, where we would just let the
> code be put to trunk and do bigger code reviews every now and then, in
> order to avoid stagnation.

I agree that something looks off when trunk has been so inactive.
However, from my perspective the cause is not merely the fact that we
are now doing code review.  My interpretation is rather thus:

* I know a number of us have been focusing on other things (i.e., the
rest of life).  For example, most of our branches have been pretty
quite during this time as well.  If all of us had been doing lots of
development in branches and all of it was waiting for review, then I
would possibly agree that code review was a bottleneck.  Also, our
relative inactivity is also seen in our mailing list activity.  Simply
relaxing our code review won't help any of these things.
* We are all new at code review and still getting used to it.  A huge
thing for me is that it is really easy for me to see what needs to be
reviewed an to do the reviews.  I think a few minor changes to our
workflow will help in this area.
* We all tend to do work in big batches = big changes, big reviews,
big merges.  I think our workflow would improve greatly if we would
force ourselves to make much smaller changes and merge more often.  I
have been working with the sympy devs recently and this is one thing I
have learned from them = code, review, merge often.  I am just as
guilty as anyone else of this.

So..., I am willing to spend some time doing some code review, but
before I do, I would like people to make sure their branch is _really_
ready for review if it has a proposal to merge.  Otherwise, delete the
proposal or mark it as "work in progress."

So...

1) It would be great if people (myself included) could start doing
smaller, more often code/review/merge cycles.  We don't want to overdo
this (like 1 commit per merge), but only merging every two months is
too long.

2) Let's clean up the proposals to merge and then start actually doing
reviews + merging.

Here are the current people with branches marked for review/merging:

Barry Wark, 1 branch (I think this actually needs review)
Ville, 3 branches, 1 of which I think needs review
Gael, 1 branch (does it need it?)
Fernando, 2 branches (do they need it?)

Cheers,

Brian


> --
> Ville M. Vainio
> http://tinyurl.com/vainio
>