[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
The Xanadu 9 Point Plan For Merge Management
- To: <xanatech>
- Subject: The Xanadu 9 Point Plan For Merge Management
- From: Marc Stiegler <marcs>
- Date: Mon, 30 Apr 90 21:26:10 PDT
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
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
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