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

Glyph Lefkowitz glyph at twistedmatrix.com
Wed May 26 02:39:00 MDT 2010


On May 23, 2010, at 10:35 PM, exarkun at twistedmatrix.com wrote:

> On 23 May, 12:26 am, glyph 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.

That's about the size of it.

> 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.

Great.  I propose some core committers try it out however makes sense to them, on whatever the next obvious thing to try it on is.  Rather than try to document the whole process up front, please just spell out what you expect the reviewer to do on each ticket placed into review this way, and we'll document the process after we've nailed down something that works.

> Of course, someone needs to work on something big before we'll have a 
> chance to try it.  I'm not yet convinced that `URLPath` is a good case 
> for this, though.  It's very little code, and a complete 
> reimplementation (if even such a thing is needed) will likewise be very 
> little code.  Also, I don't think a complete reimplementation is needed 
> here.

Yeah, like I said: I just grabbed that example because it was handy, not because I thought it was particularly appropriate.  I don't even have anything in particular in mind.  I actually wanted to bring this up while we were *between* major things, so that we could avoid discussions of specific problems with a current branch or feature (once something's in the middle of being implemented it develops a life of its own, and this is often an emotional context in which to talk about process changes).

> Going back to the proposed workflow change, we should also be sure 
> there's a clear condition under which the integration branch should be 
> merged to trunk.  And ideally we should still try to keep the lifespan 
> of these things as short as possible.

My proposed criterion would be that the integration branch has an associated ticket, with links to a list of all other tickets expected to be a part of it.  When all tickets on that list are closed, it can be merged at any time.  This would, however, leave the door open for a reviewer to say "#XXXX is okay to merge, but based on my review really need to consider #YYYY before it can be merged to trunk, so please add that to the integration branch list".  Of course, in the interest of keeping these lifespans short, this suggestion should be used sparingly.  But it would be good for things like "update the documentation and examples" or "I noticed that the old system had feature X, we really need to keep parity with that before we deprecate it".

I still like the idea of a final sanity check, but based on jml's feedback about Launchpad perhaps it would be best if we kept that step optional.  Especially since I can't think of a clear set of guidelines for reviewers at that stage.  (I mean, they *should* check for all the same stuff one normally checks for; coverage, documentation, etc, but they *shouldn't* block the merge from going to trunk while they re-audit every changed line of code, as that defeats the purpose of having incremental reviews in the first place.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20100526/484d7da0/attachment.html>


More information about the Twisted-Python mailing list