[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