Joost Baaij <joost@spacebabies.nl> writes:
> > It's important that the build and test suite be in a happy state in
> > the repository most of the time, to facilitate parallel development.
> > If I've checked in code that breaks "make check", then it's going to
> > be harder for others to test their own changes, even though their own
> > changes might not be related to what I'm doing.
>
> Should anyone be allowed to check in code that breaks any tests?
> Personally I think someone should only commit code when all the tests
> pass on his/her local machine.
The loose rule is "Please don't breake the build or 'make check'."
The best thing is to just make sure the test suite still passes, yeah.
It's okay to break things when avoiding the breakage would cause big
inconvenience for the committer, though. Just make sure to announce
that you broke the build, so others can use previous snapshots (i.e.,
"cvs update -D ...") while the breakage is in effect.
It's also okay to comment out a test. For example, if you need to
commit up so a co-developer can reproduce a problem, but your current
changes break a test, then just disable that test. You'll continue to
work and re-enable it when its ready; in the meantime, the automated
nightly builds & tests won't raise an unnecessary red flag, and other
developers will not be needlessly worried by having their "make
check"s fail.
(Eventually I'll put the above in the HACKING file; just waiting for a
consensus, or at least a lack of objection, from other developers
first.)
Best,
-K
Received on Sat Oct 21 14:36:26 2006