When the process gets in the way

Having gone through the migration from CVS to SVN and from our internal, rather onerous bug and change tracking system to Trac I suddenly find that we have lost the plot.

We started out attempting to improve our processes with a view to simplifying procedural requirements and reducing the load on engineers so that they could get more work done.

Now I find that the group driving these changes has become so focussed on the processes and procedure that considerations of minimising the procedural requirements while maximising their benefits has all but gone.

Essentially we got into a bike shed argument (which I started) and we all know that it is impossible to resolve those.

So here's the question:

If you enforce having a Trac ticket number in every commit and you do a lot of internal releases of your code should you open a single ticket and log all release commits to that ticket or should you have one Trac ticket per release? An acceptable answer is to allow both approaches.

What do you think?

Tue, 2006-11-28 08:52
( categories: )

It's not one or another

Well, at first sight I think you are trying to tie strongly what a ticket means with what a commit is.

Tickets should not dictate how commits are done, neither viceversa. Tickets are used to track tasks, issues, requests, enhancements, not to define how developers perform a commit. Neither commits define how tickets appear.

I know clearly that there could be always a relationship between a ticket and a commit. Each commit could correspond to a particular ticket, but you should force the developer to only commit changes for that ticket, which could have conflicts, because some developers work for more than a ticket at the same time and maybe changes are applied to more than a ticket.

A single ticket may consists of several commits, one should not wait so much to perform a commit, because it will cause more conflicts and code merges slower, you should integrate fast instead.

What is true, is that releases should satisfy a specific functionality, as defined by one or more requirements.

Is depends of your context, but analyze properly how your team works, how granulated are your tickets, and how much functionality should releases include, and do not overload developers with so much policies and procedures that makes an easy thing as to perform a commit a trouble.

I my case, i would not consider to choose one or another approach, but determine when one is needed, and when the other is needed instead. Both approaches can live together, always respecting what is appropriated according to the circumstances.

Re: It's not one or another

To clarify, my system permits commits for many tickets, the comment is searched for InterTrac links to tickets and each ticket mentioned has the commit message added to it.

I also permit many commits to a single ticket. This is one of the more useful features of forcing ticket numbers on commits - you get another view on code history which is by subject (ticket) rather than a simple timeline on a Subversion URL.