Change-Least Evolved Branch

[Brad_Appleton-GBDA001 at email.mot.comBrad_Appleton-GBDA001]

Richard Geiger writes:
[snip]

Pardon me for a minute ...

  AAAAAAAAAAAAAAAUUUUUUUUUUUUUUUUUUUUUGGGGGGGGGGGGGGHHHHHHHHHHHHHH!!!!

[sorry - had to do that - this is very frustrating]

Why is it that just about everything you said in that last post
regarding what you think I'm saying is even further from my intended
meaning than it was before we posted almost a dozen correspondences
apiece. Not only does this "communication" seem to be taking us
nowhere, its taking us further apart.

> E.g., what happens is the release-intention turns out to be different
> than what actually happens?

The exact same thing that would happen if the codeline intention turns
out to be different than what actually happens: You guessed wrong; You
have to fix it. There is absolutely no difference whatsoever here in the
amount of risk and the cost to fix it. None.

> Yes, if you're going to batch up changes,

Pretend the batching word never ever came up. Don't waste the energy
trying to cover it. Its not necessary and it doesn't change anything and
it just adds to the confusion. Pretend we are doing everything else
as per the other practices recommended in the "High Level Best Practices"
paper.

> If you're propagating the changes promptly, the "branch of earliest
> intended release" is a major Don't Care,

No - Please let me reintroduce the definitioin of the meaning of
"Earliest Intended Release". As I said before that "earliest intended
release" does NOT mean the earliest release of all those planned.  It
means the earliest intended release FROM AMONG THE SET OF RELEASES THAT
NEED TO HAVE THE FIX! This is the exact opposite of "major Don't Care".

So we have:

  The set of all planned releases to date.

  From this set we choose a subset, namely:

  The set of all releases the we decide absolutely must have the change
  that we need to make. Call this the GOTTA HAVE IT set of releases.

  From this GOTTA HAVE IT set we then choose the earliest planned release
from that set. This is *my* *definition* of "Earliest Planned Release".
Let this be the meaning of this phrase in this thread from now on unless
explictly qualified otherwise for each such occurrence.

> whereas minimizing merge trouble is something you _should_ care about.

I do care about it. I never said I didn't. What I said is that I don't
believe it can ever be the deciding factor for which codeline to change
(as much as you or I might wish otherwise). I believe there is another
factor that is far more dominant.

Lets dispense with the cross-talking and the previous drawings and deal
with a bona-fide, concrete example. Feel free to come up with the
initial conditions on your own and stop when you get to the point where
you think you have identified all of the codelines in which you want to
simultaneously introduce your change. Then explain to me how you
identified which codelines belong to that set and why.

MOST IMPORTANT OF ALL, PLEASE DEFINE ALL YOUR TERMS so we both know
what is meant by them and we aren't implicitly using different
definitions in our head.  I'll even let you define what is meant by
"least evolved".

Lets see if we can't at the very least, locate the precise point of
disagreement or misunderstanding (even if we can't resolve it).
- -- 
Brad Appleton <bradapp at enteract.com> | http://www.enteract.com/~bradapp/
 "And miles to go before I sleep."   |  3700+ WWW links on CS & Sw-Eng