Richard Lowe writes:
> Mike Kupfer wrote:
> >>>>>> "RL" == Richard Lowe <[EMAIL PROTECTED]> writes:
> >
> > RL> That at most a single delta contained (as comments, at least) one CR
> > RL> and one ARC case.
> >
> > 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.
> >
>
> Yes, with hindsight the logic above is obviously broken, I don't know
> what (or if) I was thinking. Sorry.
I have to dissent from the rest of the commentary on this thread,
because I think the above comment about ARC cases is equally
applicable to CRs as well.
It's often the case that some change I'm making _incidentally_ fixes
one or more other CRs. There's no way to tease out the fix for that
other CR, as it may well just represent removing a bit of broken
functionality. I don't want to close out that CR as a dup of some
other CR (it's not actually duplicate), nor just close it with some
incorrect status ("not a bug" or "not reproducible").
As a simple example of this, there are CRs 4157198 and 4978063, which
I fixed as a side-effect of fixing the DAD problems (part of 4728609).
There's no separable code there that could be identified to "fix"
those problems, no independent changeset to use, and yet the overall
putback does in fact fix them.
Trying to cut those out as separate changesets would be a bald-faced
lie. Those maintaining other versions of the software who do not want
to take the entire DAD change *MUST* cook up a new (and unrelated)
solution. Indeed, that's just what was done for 4157198.
Moreover, if I'm working on some set of changes for a long period of
time, it's quite likely that these changes become entangled. For
example, code review comments often say things like "could you use
this new function over here as well?" -- and if I do, the changes are
no longer independent units and need to evolve as one.
I think one CR per changeset may be an "ideal," it certainly seems
useful for separable things that are nonetheless putback together, but
it'd be wrong as a hard requirement.
--
James Carlson, KISS Network <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
