<html><body>I'll respond to a few specific things JML said here, but I want to get across my personal view of the purpose and benefits of the process we're using. &#160;I specifically told JML to make a branch and continue with these changes before he got started, and I still think that was the right thing to do.<br /><br />UQDS was instituted on Twisted because tracking changes to Twisted was becoming too difficult. &#160;Some changes were critical bugfixes, some were random whitespace twiddling, and some introduced regressions. &#160;It was designed in the first place (for Divmod) because we were having similar issues in a different context.<br /><br />In other words, not all change is progress. &#160;The goal of UQDS was to provide a way to encourage and ensure that all changes to *trunk* are, in fact, progress, and Twisted is always improving, so that we don't need to burn our energy tracking down bugs or gratuitously bad design decisions after they've been merged to trunk and people have begun depending on them. &#160;I think it has been very successful at meeting this goal.<br /><br />It's true that the UQDS document on the Divmod wiki does specify that the lifetime of a task in UQDS begins with the creation of a ticket. &#160;For the context that I originally wrote "If it's not in the tracker, you shouldn't be working on it.", i.e. the full-time developers at Divmod, that makes perfect sense. &#160;In a commercial environment, management needs to have a clear idea of where all the resources of the company are being deployed.<br /><br />I would go so far as to say that it makes sense for Twisted as well, insofar as UQDS manages our workflow. &#160;However, Twisted SVN does things other than UQDS (the trunk/doc/fun/Twisted.Quotes exception and the sandbox, to name two notable things) and I don't think that every branch needs to be backed by a ticket. &#160;I'd rather have non-ticketed branches that we can delete as prototypes than a profusion of vague tickets which only their author understands. &#160;(In other words, SVN branches are not always necessarily part of the UQDS workflow, but tickets are.)<br /><br />It's fine by me if there is tons of bad, broken code that gets checked in to branches (as long as it is then deleted - see below). &#160;Sometimes, the only way to learn how to implement a feature correctly is to implement it incorrectly. &#160;Sometimes the only way to figure out what feature you're implementing is to mess around for a while and see what kind of code you write. &#160;This is especially true of refactoring.<br /><br />The policy on having tickets applies to anything wanting a review, and therefore, anything that hopes to go to trunk. &#160;If you have done some work in a branch which you want reviewed, you still need to explain, for the reviewer's benefit, what it is that the change is supposed to accomplish in a ticket. &#160;Again, this is especially true of refactoring - it's fine to noodle around for a while trying to discover a better shape for the code, but once you've found one, it's important to clearly express *why* the new shape is better rather than simply different. &#160;Just because the description eventually needs to be written doesn't mean it needs to be the first thing that happens, though.<br /><br />There is one caveat to creating branches for experimentation. &#160;I think it's rude to leave dead branches around. &#160;This can be mitigated by using ticket numbers, because someone else can come along later, notice that the branch refers to a closed ticket, and delete it. &#160;Open branches have a cost: "svn ls svn://svn.twistedmatrix.com/svn/Twisted/branches" should, at a glance, give an indication as to what's in progress in Twisted right now, and dead branches obscure that view and make it difficult to get a feel for what's going on. &#160;Right now there are 133 entries there, and it's probably time for some pruning. &#160;So I think it's reasonable to say that if you leave a ticket-number-free branch around for more than a month, don't be surprised if someone else deletes it. &#160;(But please delete it yourself before it comes to that.)<br /><br />However, deletion or rejection should not necessarily be seen as a failure, either of the developer or of the process. &#160;The whole *point* of using branches as temporary development lines is that, sometimes, those lines end without reaching trunk. &#160;Each rejected branch should be a learning experience.<br /><br />Another important thing to keep in mind, as long as I'm talking about how to use and not use branches: don't *ever* deploy Twisted from a branch, and this goes triple for a branch created for experimentation. &#160;Such branches are still at the mercy of a reviewer, and may be substantially changed or deleted. &#160;Eventually, *all* branches will be deleted, as they are merged to trunk and become obsolete.<br /><br />On 08:42 am, jml@mumak.net wrote:<br /><br />&gt;&gt;This time, I decided to not file a ticket, because I did not want to<br />&gt;&gt;prematurely problem of concisely defining my work. I am being<br />&gt;&gt;chastised (albeit gently) for such work, and I will probably stop<br />&gt;&gt;working on this code.<br /><br />Please don't. &#160;This kind of clean-up can be very important. &#160;I don't know if the particular changes in this branch are, but certainly the changes which can come out of exploratory coding are useful.<br /><br />&gt;However, I will note:<br />&gt;- The time penalty of discussion is significant to me because of my <br />&gt;timezone.<br /><br />An important feature of UQDS is its asynchrony. &#160;Although branches have to be reviewed before they're merged, to the extent that changes do not directly depend upon one another, it's critical that someone be able to sit down and work on feature X, then feature Y, then feature Z, without stopping each time to wait 24 hours for a review and then again for the second review. &#160;With 24 hours (or more!) of context-switch latency, the inability to pipeline requests could completely kill development speed.<br /><br />This asynchrony should apply to all aspects of the process, including discussion of requirements and design goals. &#160;The key feature of a heavyweight (read: broken) process is that a developer who is itching to do some work has to sit around and wait for permission from a committee to do so.<br /><br />&gt;- I really do think discussion is good. However, I think that planning<br />&gt;as a group is not always worth the cost.<br /><br />Enforcement by consensus is great. &#160;Design by consensus (i.e. committee) is, unfortunately, terrible. &#160;I never intended UQDS to require that. &#160;The best sort of group design is when one person has an idea and champions it and the group offers criticism and analysis. &#160;Having the idea in the first place can require writing some code.<br /><br />&gt;My goal is more complex than making Twisted the best software<br />&gt;possible. My goal is to be able to sit down and work on Twisted even<br />&gt;if I don't have a fully specified, fully approved goal in mind.<br /><br />As I see it, irrespective of their priorities, the latter is a prerequisite for the former. &#160;If, as an open source project, we can't harness the power of people's idle time, I think we're doomed.</body></html>