Rick Hillegas wrote: > In previous lives, I've seen code-coverage metrics generated on, say, > a monthly basis and used as a release barrier. I do not think they are > appropriate as a barrier to checkin. > I think since we seem to be going for very long release cycles instead of the release early, release often model, release barriers are not very effective for maintaining quality on the trunk. Also in open source, developers come and go so the wait until release model doesn't tend to work that well in that regard either. If Linux could release a new kernel twice a day, I tend to think that the trunk should be "ready for release" at any time for completed functionality and even incremental functionality could be covered.
Kathey
