How do I protect the trunk from hapless newbies?

Posted by Michael Haren on Stack Overflow See other posts from Stack Overflow or by Michael Haren
Published on 2009-05-07T17:13:04Z Indexed on 2010/03/29 5:03 UTC
Read the original article Hit count: 297

A coworker relayed the following problem, let's say it's fictional to protect the guilty:

A team of 5-10 works on a project which is issue-driven. That is, the typical flow goes like this:

  1. a chunk of work (bug, enhancement, etc.) is created as an issue in the issue tracker
  2. The issue is assigned to a developer
  3. The developer resolves the issue and commits their code changes to the trunk
  4. At release time, the frozen, and heavily tested trunk or release branch or whatever is built in release mode and released

The problem he's having is that a couple newbies made several bad commits that weren't caught due to an unfortunate chain of events. This was followed by a bad release with a rollback or flurry of hot fixes.

One idea we're toying with:

Revoke commit access to the trunk for newbies and make them develop on a per-developer branch (we're using SVN):

  • Good: newbies are isolated and can't hurt others
  • Good: committers merge newbie branches with the trunk frequently
  • Good: this enforces rigid code reviews
  • Bad: this is burdensome on the committers (but there's probably no way around it since the code needs reviewed!)
  • Bad: it might make traceability of trunk changes a little tougher since the reviewer would be doing the commit--not too sure on this.


Update: Thank you, everyone, for your valuable input.

I have concluded that this is far less a code/coder problem than I first presented. The root of the issue is that the release procedure failed to capture and test some poor quality changes to the trunk. Plugging that hole is most important. Relying on the false assumption that code in the trunk is "good" is not the solution.

Once that hole--testing--is plugged, mistakes by everyone--newbie or senior--will be caught properly and dealt with accordingly.

Next, a greater emphasis on code reviews and mentorship (probably driven by some systematic changes to encourage it) will go a long way toward improving code quality.

With those two fixes in place, I don't think something as rigid or draconian as what I proposed above is necessary. Thanks!

© Stack Overflow or respective owner

Related posts about project-management

Related posts about version-control