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

Jonathan Lange jml at mumak.net
Mon May 24 05:42:46 MDT 2010


On Mon, May 24, 2010 at 3:35 AM,  <exarkun at twistedmatrix.com> wrote:
...
>>So: thoughts?  Does this make sense as a policy change for facilitating
>>the development of major new features or consolidating behavior-
>>changing fixes into easier-to-understand units?
>
> So, to summarize, we could stage our code using more than just two
> branches (trunk + feature branch) in order to make larger changes easier
> to understand for reviewers while still making each change to trunk a
> coherent unit.
>

FWIW, we've been doing this on Launchpad for some years and it works out well.

As a rule, we don't have the final "sanity check" review, since we
have robot minions that check for conflicts and that the tests pass.

> This sounds fine to me.  We need to work out some details (like, for
> example, I'm not sure trying to do this using subversion is such a good
> idea, and we want the process to be documented somewhere so we don't
> have a repeat of #886), but I think we should try it and see what
> happens.
>

Using a DVCS would make it much easier. For example, Bazaar has
plugins like loom and pipeline that are designed to manage a stack of
changes.

Also, +1 on the documentation.

jml




More information about the Twisted-Python mailing list