Quoting Bob Jamison <rjamison@...357...>:
However, a couple of things will help:
- Before someone knowingly breaks the tree, they should
warn everyone to stop updating their cvs copies until it is fixed again. That way they can continue to work on their features/bugs.
In this case, I _had_ warned the list since I felt the commit was slightly risky. I wouldn't have comitted if I'd known for sure there would be breakage (I did do some perfunctory testing).
Note that we're early in a heavy development cycle, not leading into a freeze. IMO, a risky checkin here shouldn't be as much an issue here as it ought to be when e.g. leading into a freeze, so I weighted my risk/reward evaluation a bit differently than I would have otherwise.
- Try to limit the scope of the breakage. If it can be limited
to a directory or two, please do so. Break it, fix it, then break it again later.
?
If you're referring to compile breakage, that's never acceptable to do knowingly.
Otherwise, functional breakage really isn't related to the filesystem like that. Either the breakage is related to a specific feature, or it's part of core code that is unavoidably going to have widespread repercussions. It's still best not to do knowingly.
(FWIW, checking in a new feature that doesn't work yet does relatively little harm, I'm just talking about regressions in existing code, or build failures)
In short:
1. Don't deliberately break something in HEAD that used to work.
2. Early in a development cycle, breakage is still going to be more frequent and everyone should plan for this (e.g. as a matter of course I save "known good" builds to use for production work)
3. Keep existing unit tests up-to-date (test breakage is breakage too). I have been entertaining a proposal that we adopt Tinderbox and include "make check" in the build actions...
4. If you don't feel like an important bug is getting addressed quickly enough, and there's no bug filed, file a bug with an appropriate severity, dammit.
-mental