On Thu, Dec 07, 2006 at 09:10:50PM -0800, Mike Kupfer wrote: > I think we want to allow multiple ARC cases. It's not unusual for a > project, particularly a large or complex one, to have multiple ARC > cases. The ksh93 project is working on at least its third ARC case.
Certainly. > First, if a changegroup has multiple changesets, what are the > requirements for those changesets? Do they have to individually build? > Do they have to be individually revertable? Yes. I think that needs to be an invariant. With appropriate common sense, you shouldn't have to do a full nightly for each changeset unless it's sufficiently complex. Tightly interwoven, complex bugfixes can probably just be merged into a single changeset if that's the way the development was done. I've got a diff/patch side project going on in mercurial/mq control, and (when I've had time to actually look at it), I've found that keeping each of the half dozen or more bugs that I'm working on there separate from the others isn't too much of a stretch in my mind, and being able to look at the diffs individually helps me comprehend each fix better. I trust mq to get the compounding right so that the final result is correct, and the unit testing for each bug is pretty straightforward. Larger, wholesale rewrites of things might make that kind of separation difficult; I certainly get that. > Second, consider this scenario: bug A is that an application fails to > check the return value from a malloc() call. Bug B is that the > application is slow in some situation. As part of fixing bug B, I > restructure the application, and the offending malloc call goes away > completely. If the changeset can only have a single CR, what do I do > here? Mark bug A as not reproducible, cross reference the two bugs, and put only B in the comment. In the unlikely event of a water landing^W^Wbackout, it would be your responsibility to reopen A until you could get B back in. (Or wait to close A until B is marked Fix Delivered.) I get your point, though -- there are probably reasonable cases that can be constructed where lumping multiple bugs together in a single changeset is going to be immeasurably easier than trying to tease them apart. I think that with some discipline, those cases will appear infrequently, though as a gate policy, I think that we should work gently towards one changeset <-> one bug slowly, until people are used to the tools, and even then recognize that it's not always going to happen. Danek _______________________________________________ tools-discuss mailing list [email protected]
