Kevin Dietz

From CitconWiki
Revision as of 08:22, 9 April 2008 by 75.70.249.156 (talk) (New page: I was the person Timpani Software. We make BuildBeat. Information on BuildBeat can be found at [http://www.buildbeat.com] I really enjoyed the conference. As I said in my closing remar...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

I was the person Timpani Software.

We make BuildBeat. Information on BuildBeat can be found at [1]

I really enjoyed the conference. As I said in my closing remarks, I really do feel a bond with the group that I don't get in my everyday non-work life. It's fun to be around people who are thinking about the same things I'm thinking about and trying to solve the same problems I'm trying to solve.

For those who missed my talk on feature branches in a continuous integration environment, the consensus seemed to be that you shouldn't do branches unless absolutely necessary because it adds a lot of overhead that isn't worth the benefits in most cases. I'm still curious about the concept of feature branches, however, and I'm wondering if there are ways to improve the current state of the art so that feature branches can exist more peacefully in a continuous integration environment. It could be that my interest in feature branches stems from the phase Timpani Software is in right now with the development of BuildBeat. I've got a lot of major changes I'd like to work on independently. I don't know how long each feature will take, and some of them are a bit experimental and may be abandoned if they don't work out. I just don't want to mix all this stuff up into an unstable trunk. Also, since my team is small, I'm not too concerned about the problems with merging and merge conflicts caused by branching.

- Kevin