[Twisted-Python] version control, QA, branching ...
acapnotic at twistedmatrix.com
Wed Sep 11 17:55:13 EDT 2002
I caught some bits of a discussion on #twisted on my way to bed last
night, and thought "Hey, I should read that." So I plundered the logs
and did a lot of pruning and here you are, a discussion involving
quality maintance practices with version controlled branches and unit
tests and things. [attached]
Keep in mind that this log HAS been trimmed by me, and while I have made
an effort to maintain context, it's quite possible that you aren't
seeing the full context for every remark made.
Random notes from me:
* Michael Schwem was telling me about
[http://aegis.sourceforge.net/ Aegis], which sounds like it's
*much* better at branches than CVS is, and pays much stricter
attention to the entire QA process.
* In my recent romp through CVS resources, I found
[http://codestriker.sourceforge.net/ CodeStriker]. I haven't
talked to anyone who's used this, but it has some ideas in it.
-------------- next part --------------
[05:26] <glyph> radix and I had some discussions about release procedure today, btw :)
[05:26] <glyph> we came to some pretty radical conclusions
[05:27] <itamar> glyph: and they were?
[05:27] <glyph> itamar: release candidates should always be made from HEAD
[05:27] <glyph> itamar: Twisted developers need to learn how to use branches for developing experimental features; HEAD should *always* be releaseable
[05:27] <itamar> branches, here we come
[05:28] <glyph> itamar: the better tests we have, the less craziness with branches is necessary.
[05:36] <fzZzy_> glyph: shall I check in highly untested domtemplate=>microdom code? or wait, and test it some more?
[05:36] <fzZzy_> I guess this goes back to the cvs branch issue
[05:37] <dash> fzZzy_: well, isn't testing it easy? =D
[05:38] <fzZzy_> dash: not at 2:30 am
[05:38] <fzZzy_> and no, I never wrote any domtemplate tests
[05:39] <dash> fzZzy_: no domtemplate tests?! gasp
[05:39] <dash> fzZzy_: you sound like me
[05:39] <fzZzy_> ok I'm going to bed instead since glyph didn't respond instantaneously ;-)
[05:39] <fzZzy_> I'll be banging on it tomorrow
[05:40] *** glyph has changed topic to "Welcome to the Twisted project: sleazeware produced in a drunken fury by college dropouts!"
[05:40] <dash> glyph: !!!
[05:40] <dash> glyph: I GRADUATED
[05:40] <glyph> dash: you didn't write most of twisted :)
[05:40] *** dash waves diploma madly
[06:15] <glyph> jml: much like linux; even very stable kernels with frozen APIs contain "experimental" drivers and such
[06:15] <jml> glyph: so the trick is to mark them as such?
[06:15] <glyph> itamar: I don't think that's the case; in Twisted's history we've had releases that were pretty stable and didn't require a lot of after-the-fact tweaking
[06:16] <jml> glyph: for many commercial packages, it's not that long after release that you get SP1.. no one really thinks it a bad thing.
[06:16] <jml> just as long as code-breaking changes aren't slipped under the door.
[06:17] <glyph> jml: I am increasingly confident in our test suites lately
[06:17] <glyph> jml: we seem to have had relatively few problems with code-breaking stuff slipping in without anyone noticing :)
[06:17] <jml> glyph: btw, how's the test-first design going? I've found it hard in the past to keep disciplined about it.
[06:18] <glyph> jml: it's hard to keep disciplined about it for me too
:-(. When I can do it, it's *definitely* better than the other way.
[...a big discussion on one-point-oh philosophy intervenes here. Only
a few tangentially related bits are included in this log excerpt...]
[06:22] <glyph> itamar: in "policy": we don't have a policy for continuing development of Twisted after 1.0, in terms of legacy support of APIs that may need to change for some reason. (Yes, some large portion of twisted.internet is stable, but what is our support policy for the *other* portions of twisted that you *need* to use for a useful app? Are they just unsupported continuing forward?). We don't have a policy for releases which is sustaina
[06:23] <glyph> this includes things like "when should developers use a branch?" and "how should the release manager interact with users in order to decide whether we mihgt be breaking something important?"
[06:27] <glyph> itamar: but then, a developer has some feature they want to play around with, which they believe to be potentially unstable, but doesn't break any tests
[06:27] <glyph> what are the guidelines for them to work with that?
[06:52] <moshez> glyph: which reminds me.
[06:52] <glyph> moshez: hmm?
[06:52] <moshez> glyph: tell radix to fix ReleaseProcedure
[06:52] <glyph> moshez: we've talked about changes to ReleaseProcedure
[06:52] <moshez> glyph: I left a note there what he should fix
[06:52] <glyph> moshez: OK
[06:53] <moshez> glyph: I'm not talking about changes to the procedure, just bring the document up todate on reality.
[06:53] <glyph> moshez: I don't see the note :)
[06:54] <moshez> ---- This part is sorely out of date -- document the new Debian way --
[06:54] <itamar> oh
[06:54] <itamar> new policy is to do all major devel on brances?
[06:55] <itamar> better mail the list then
[06:55] <glyph> itamar: that's a proposa, still need to hash it out, and to make sure that it is SUPER EASY for developers to do this
[06:55] <itamar> it sounds painful
[06:55] <moshez> glyph: it isn't.
[06:55] <itamar> but it probably is easy
[06:55] <moshez> glyph: it isn't even mildly easy
[06:55] <moshez> glyph: I'm not sure I like that propsal actually.
[06:56] <glyph> moshez: I figured you wouldn't :)
[06:56] <itamar> here we go again
[06:56] <glyph> but I'm not really sure what you wouldn't like
[06:56] <itamar> it may make more sense to branch on each release
[06:56] <moshez> glyph: merging is hell on earth
[06:57] <glyph> moshez: that gives the developer incentive to integrate early, as well as provide backwards compatibility hooks and good tests so that he doesn't have to hang out in a branch for too long :)
[06:58] <warner> my exp: each branch doubles the total effort. don't branch unless you know you won't do much work on one of the paths
[06:58] <glyph> moshez: when radix and I discussed the policy, we were also debating the need for coverage tools in order to qualify particular changes for branches
[06:58] <moshez> glyph: how do you decide which changes go on a branch and which go on HEAD?
[06:58] <glyph> like if the module you are planning to restructure has 95% unit test coverage, chances are you can get away with not having a branch at all, provided you don't change tests
[06:59] <moshez> glyph: and woulnd't it just make sense to say "never break unittests"?
[06:59] <glyph> moshez: yes, that makes sense
[06:59] <itamar> possibly the effort should go into more tests
[06:59] <itamar> instead of branches
[06:59] <glyph> itamar: that would be optimal
[06:59] <itamar> ugh
[06:59] <itamar> this is too distracting
[06:59] *** itamar has quit IRC ("must work") (~itamar at line102-187.adsl.actcom.co.il)
[07:00] <glyph> i win!
[07:00] <moshez> "Finish Him"
[07:00] *** glyph isn't clear what that would entail, since itamar's already disappeared
[07:01] <glyph> moshez: So yes, "never break unittests" is good, but if you're doing work on, for example, cReactor, there just isn't good enough coverage to be sure that you're OK to check in to a branch which should be always-releaseable (HEAD), even if unittests are A-OK
[07:02] <moshez> glyphy: and when would the merge from the branch to HEAD happen?
[07:02] <glyph> moshez: after our army of simean warriors bashes on the code for several weeks
[07:03] <moshez> glyph: in other words "after several weeks pass"
[07:03] <glyph> moshez: i need to read up on the exact mechanics of branches in order to understand your concerns, I think
[07:03] <moshez> glyph: ok. do so.
[07:03] <glyph> is it not possible for a developer to continuously re-integrate patches to HEAD into their branch?
[07:03] <moshez> glyph: wait.
[07:05] <moshez> glyph: http://www.lerner.co.il/~moshez/cvs/cvstut34.html
[07:05] <warner> glyph: in my experience, yes
[07:05] <warner> glyph: however the question of "should I or not" takes up as much time as doing the commit separately to both branches
[07:06] <glyph> warner: hmm
[07:06] <glyph> warner: what was your experience working with branches?
[07:07] <moshez> http://cvsbook.red-bean.com/cvsbook.html#Going_Out_On_A_Limb__How_To_Work_With_Branches_And_Survive_
[07:08] <glyph> moshez: ugghh
[07:08] <glyph> moshez: the 'spurious conflicts' bit is ... interesting
[07:09] <warner> well, the workfolk kept alternating between the "current on HEAD" and "current on branch" schemes
[07:09] <warner> the biggest problem was that people expected the merge features to mean they could do less work
[07:09] <warner> but the real issue was who decided which bugs/features should get done in which releases
[07:10] <moshez> glyph: I am evil
[07:11] <glyph> warner: hmm
[07:11] <warner> basically foisting developer work off to the config mgmt people, who didn't know the code well enough to say yes or no
[07:11] <glyph> okay, I worked with branches in perforce
[07:11] <glyph> they made *waaaay* more sense than this
[07:11] <glyph> I think cvs's semantics are broken
[07:12] <warner> yup, P4's scheme is easier to work with
[07:12] <glyph> at the very least, they're not what I want ;)
[07:12] <warner> the workfolk took the other path out: ClearCase
[07:12] <warner> That was two years ago and they're still trying to figure out how it works.
[07:12] <moshez> glyph: well, if we moved to SVN, we'd have easier branching
[07:13] <warner> But at least it's expensive. They get good use out of their big NetApp boxes too.
[07:13] <jml> I suppose subversion is out of the question?
[07:13] <warner> I tend to see CVS's painful branching as similar to the 8-char tabstops in the linux kernel..
[07:14] <warner> .. a bug that makes you aware of just how bad it is to overuse that thing..
[07:14] <warner> .. if you were to fix it (or find a tool that did it better), you'd be tempted to use it more, and that would be bad.
[07:16] <glyph> jml: Well, I originally really didn't want to consider it, because I thought that there would be funding for a Twisted-based version control system in the near future
[07:17] <jml> understandable. I disagree though.
[07:18] <glyph> jml: Well, the funding didn't appear as expected (though it still will at some point, most likely about a year from now), and this is the first time I've really wanted a feature which svn potentially implements better
[07:18] <glyph> svn's infrastructure strategy frankly scares me though
[07:19] <warner> twisted.revisions? my brain hurts
[07:20] <jml> glyph: yeah, fair enough. I'm quite happy to have at least one or two network apps that aren't twisted, but that's me.
[07:20] <warner> or maybe that's just the lack of sleep
[07:20] <glyph> warner: your brain hurts? *your* brain hurts?
[07:20] <glyph> warner: YOU HAVE NOT YET COME TO KNOW PAIN, MORTAL
[07:20] *** warner laughs
[07:23] <phed__> twisted.revision features: every client is also a server. you create a branch every time you edit a file. versioning is measured in minutes. realtime versioning. integrated QA
[07:25] <warner> "integrated QA": my current learn-as-I-go Twisted project is a tinderbox-like distributed build network, including various forms of 'make test' stages
[07:25] <glyph> warner: awesome!
[07:25] <glyph> warner: is this going to be publicly available?
[07:26] <warner> I'm basing it off CVS commit messages, but direct-from-VC would be better
[07:26] <warner> glyph: yup. I did a similar thing for work (before I found twisted), now I'm rewriting it without the shackles of employment
[07:27] <glyph> warner: are you using CVSToys?
[07:27] <warner> glyph: nope. whazzat?
[07:27] <glyph> warner: ooooohhhh
[07:27] <glyph> http://twistedmatrix.com/users/acapnotic/cvs.png
[07:27] <moshez> http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING
[07:27] <glyph> warner: talk to acapnotic :)
[07:29] <warner> glyph: will do. if I guess correctly about what it does, it would get rid of yet another piece of code I need to write. Just like twisted did for the entire serialization and transport layer.
[07:30] <warner> (if I wait long enough, the rest of the necessary code will disappear too. love it.)
[07:31] <glyph> warner: cool :)
[07:31] <glyph> warner: hey wait
[07:31] <glyph> warner: you know, we could really use something like that
[07:31] <glyph> warner: I keep meaning to write an automated unit-test runner with e-mail notification
[07:33] <glyph> I'm going to go to sleep for about 16 hours right now
[07:33] <glyph> talk to you crazy cats later
[07:33] <warner> glyph: that'd be part of it. Of course with twisted you'd get an IRC bot too. The motivation back at work was to punish folks who broke the build. The status output was a web page they'd refresh every once in a while until they saw their changes were built successfully. But I'm planning on Gtk clients too.
[07:34] <warner> catch you later glyph. I'll let you know what I code up.
More information about the Twisted-Python