On Sun, Apr 15, 2007 at 09:00:32PM +0200, Eric Y. Kow wrote: > On Sun, Apr 15, 2007 at 18:37:49 +0100, Dave Love wrote: > > I'm puzzled why the test should be in a separate patch. I expect the > > code, doc, and tests for a change all to be in one patch(set); > > otherwise it rather seems to defeat the object of patchsets. Anyway > > I've split it, of course. > > Actually, I'm not sure myself. > > Instinctively, I could see that it might be nice for the source to > standalone from the tests, so you would still have changesets touching > multiple files, just in certain discrete blocks. But it does also sound > convincing to say that the tests really do go with the code and so > should belong together.
It can be nice to have a test-suite patch that is separate, as it allows one to reject the code (which might have problems), but accept the test, which might accurately describe what we want to do. I wouldn't make this a hard and fast rule, though. I like separate test patches for things like bug fixes, as that way the bug report can be accepted separately from the actual code. Test patches for new features might make more sense to include with the code itself. Except that many (most?) new features will require several patches, in order to express what's being done in a logical manner, in which case it would also make sense to split out the tests into a different changeset. We don't have a tradition of accepting tests that fail, but it might be a good idea to consider accepting such tests into unstable, and maybe even into the stable repository, if the test reveals a regression that we *really* want fixed in a timely manner. Although it is sort of scary having any repository that doesn't pass its own tests... -- David Roundy http://www.darcs.net
signature.asc
Description: Digital signature
_______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
