The Xanadu 9 Point Plan For Merge Management

[Marc Stiegler <marcs>]

As many of you have probably deduced from the xanatech discussions 
of late, the merges have become a serious bottleneck. These merges 
are the times when we bring together all the changes that have 
been made by all the programmers, into a wonderfully new, nightmarishly 
different, Xanadu.

During this past week, I have been collecting ideas for improving 
the merging process. I am surprised, almost astonished,  by the 
number of good ideas we came up with. I think just about every 
person on the team made helpful suggestions, so credit goes to 
everyone. I would also like to explicitly thank kelvin for his 
description of the integration process at Autodesk, which has 
heavily influenced some of the plans described here. 

I believe the following 9 Point Plan will dramatically increase 
our productivity from here out.

Point 1:  Mr. Eric Hill has been designated to act as Integrator. 
Hill, ravi, and hugh have all acted as integrators from time 
to time, but henceforth Hill will have something no Xanadu integrator 
has ever had: he now has the authority to hold back changes from 
the merge as he sees fit.

Point 2: A key reason why Mr. Hill may reject a change is if 
the change has not already been compiled under C++. By requiring 
successful compilation before Integration begins, Mr. Hill will 
not face the double whammy of getting things to work at 
all, while in addition getting them to work together.

Point 3: If you are really excited about a particular change, 
you are urged to write a test routine, and submit that to Mr. 
Hill along with the change. There is a much higher chance that 
Mr. Hill will test  the change, if you give 
him a test to use :-) And there is a MUCH higher probability 
that you will know whether the change was included or not, if 
you can see the test results :-)

Point 4: If you have a desperate need for a merged version of 
the system, you can negotiate with Mr. Hill to get a copy of 
the image as soon as it runs in smalltalk, without waiting for 
the completion of the cycle that includes compiling, linking, 
and testing in C++. Caveat User :-)

Point 5: Mr. Hill will complete an enhancement to our environment 
which will automatically put printfs at the beginning of selected 
methods, allowing us to get a method trace from the C++ while 
executing. This will accelerate the rate at which we can find 
the bugs that appear in C++ even though it runs in smalltalk. 
Such only-C++ bugs are very rare, but very, very expensive to 
dig out. 

Point 6: Mr. Hill will get a Sun Smalltalk, which should dramatically 
increase his turnaround time on the translate/compile cycle.

Point 7: Ravi will complete the already-planned enhancement to 
the environment that will automatically track who created the 
version of the method you're using, so you know who to ask if 
you're puzzled by something.

Point 8: By far the worst part of a merge is fixing modules which 
have been worked over by several different people. Therefore, 
every module will be assigned to an Owner. When you need to change 
a module, you should not only change it in your own image, but 
tell the Owner about it as well. Then you and the Owner can do 
a minimerge, so that the full complexity of the overlapping changes 
never appears in the Integration.

Point 9: In order to support minimerges, ravi will enhance the 
environment so that every module has its Owner listed in the 
outline browser. Then, when you do a fileout, separate fileouts 
will be created for each Owner. In other words, you will get 
one fileout for all the changes you made to markm's modules, 
one for the changes you made to hugh's modules, and so on. So 
a simple fileout will create the change lists you need for minimerging. 


Points 8 and 9 together are particularly exciting: by making 
the minimerge straightforward, we can increase the parallelism 
in the merging process, while taking advantage of the most expert 
local knowledge for each component. We may be able to make the 
big Integrations pretty straightforward regroupings of preplanned 
chunks.

We'll see.

--marcs