I've been asked (viz. IRC) to write up some thoughts, and send them to -dev for reflection. These are things that, on the one hand, I feel very strongly about, and implement in my own workplace, but on the other hand, don't push very hard here, for the simple reason that I don't participate very much in the actual day-to-day coding here.
If I were smart, I would start this as two separate threads, but I'm not, so I won't. There are two topics. Branches, and releases. But they are deeply intertwingled, so I'll keep them together. So ... where to start. Releases. We have been sitting on the 0.6 release for friken ever, because it's "not ready yet." I challenge this notion, and the entire way that we decide that a release is "ready". I assert that anybody (committer) at any time should be able to say "I'm going to do a release now." They will cut a release tag. They will produce a release candidate tarball, and put it out there for testing. After an appropriate time (1 week?) if there are no show-stoppers or vetoes, they will release it. This notion that feature X is inextricably tied to release Y means that we are stonewalled if feature X doesn't come along as quickly as anticipated. And so we don't do release Y, and the months creep by, and people forget that we're here. We should do a release every time that trunk is stable, and has anything interesting in it that it didn't have in release n - 1. Version numbers are arbitrary and meaningless. Promising feature X in release Y is silly. Promise feature X, certainly, but continue to do periodic releases whenever we have a stable product. Obviously, there's a sweet spot. If we release every week, nobody will ever upgrade. On the other hand, if we release every six months, the upgrade will be so big, and so disruptive, that folks won't want to do it. When I do releases at work, I use a very simple metric. I run 'svn log' from the last release revision number, and if the resulting release notes are too long to email to my manager, I've waited too long. (I strip out the "fixed the typo" and "changed the color" kinds of messages. I'm talking real changes.) I propose that we use a similar metric here. If a bunch of stuff has changed, and trunk is almost stable, then someone should branch trunk, stabilize it (ie, remove stuff that's half-way done) and release it. The other thing I wanted to bring up is branches. There seems to be a stigma about branches around here, and I think that there are two main reasons. First, there's the "branches are hard" reason. This can only be solved via education and experimentation. And, necessarily, the more often we use branches, the easier it will become. Here's my rule of thumb at $work. If it's going to take you longer than today to implement it, make a branch. Sync your branch with trunk every morning. I would be delighted to give any assistance necessary to folks attempting to maintain branches. The second reason branches are bad is a social one. Someone makes a branch. They don't tell anybody about it, and when they're done, they dump a crapload of new code into trunk and everyone says, where the hell did that all come from?!?! There's also the VERY MISTAKEN notion that this branch is mine, and nobody else is welcome. (Note that this can be either from the side of the brancher, or everyone else looking in, even if it wasn't intended by the brancher.) There are several important solutions to this, that all boil down to communication. When you make a branch, you must tell everybody about it, and invite then to come play with you in your sandbox. A branch with only one developer is prone to failure, for many reasons. Every one of our so- called working groups should probably have a branch. We could hand out commit privs to individual branches, but I tend to think that this is micromanaging. Everyone is welcome in every branch. There's also apparently a feeling that if you commit something to a branch, and it doesn't end up getting accepted into trunk, that it was wasted effort. I don't know how to fix that, but I do know that the more often you make branches, the less that feeling impacts anybody. Branches are for experimentation, and there's nothing intrinsically bad about discarding a branch. It should have been a learning experiment. But I can understand feeling bummed out if you put your heart and soul into a branch that then got discarded. Anyways, this is getting really long, but summarizes most of what we discussed on IRC, and my general philosophy on these points. Note that this is not merely philosophy-in-a-vacuum, but is how I run my IT department at work, and it's also how the HTTPD project at Apache works. -- http://feathercast.org/ --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
