On May 23, 2010, at 10:35 PM, exar...@twistedmatrix.com wrote:
> On 23 May, 12:26 am, gl...@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.)
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
