Stephane Ducasse wrote:
> 
> ...
> Tell me how you want us to proceed. because if we have to check all the
> removals
> this may be really a tedious process and still I think that this would
> be better that the maintainer of the removal checks if there are
> clashes for practical reason.

This is a good question.  Since both the KCP work and the package removals are
significant changes, there will probably be some conflicts, although hopefully
not too many.  This is why our 3.6 plan proposal lists a sort of rough
ordering of priority, so that we do one before the other.  (Trying to do them
both at the same time would probably be more difficult.)

The big question is whether to do the package removals first, or the
KCP/MCP/etc. work first.  Whoever goes first does have the easier job. :-)  

I think it probably is best to do the removals first, simply because getting
started on splitting up the image is the most important goal of 3.6, and it's
probably a generally good strategy to start on the most important stuff first,
just to make sure it gets done.  The KCP stuff is also important, of course,
so we'd want to start on that soon after the removals.

So unfortunately I guess this means that you will need to check for conflicts
with the removals.  However, I don't think this will be *too* difficult if you
use some tools.  My ConflictChecker tool, which is on SqueakMap, was designed
to look for these sorts of conflicts.  (See also
http://minnow.cc.gatech.edu/squeak/3156 .)

If you used the ConflictChecker, you could load the package removals first (in
the latest 3.6alpha actually, with updates going back to 3.4), and then use
the "check conflicts" menu in the filelist for each KCP changeset.  This would
be easier if you have combined your changesets into a smaller group, so that
you don't have to check 47+ changesets one at a time.  (The ConflictChecker
should be able to check for conflicts with method removals.  And it would also
automatically check if there were any other conflicts between the KCP stuff
and the updates so far from 3.4->3.6alpha.)

Or, the other approach would be to start with an image with all of the KCP
changes loaded (into a 3.6alpha image preferably), and then check each package
removal changeset for conflicts.  This would only be 10 changesets you'd have
to check, so it would probably be easier.

Then, once you had your list of conflicting methods (hopefully not large), you
could forward them to the appropriate package maintainers so that they update
their packages.  (And probably post the list to squeak-dev to be safe.)

Does this sound reasonable?  I can help you out with using the ConflictChecker
if you want to try that.

Since we are (kind of) allocating a specific time to work on the KCP stuff, we
(Harvesters & Guides) will try to devote our attention to it at that time, so
that the harvesting can move along at a good pace.  Perhaps the KCP harvesting
may overlap with the MCP and other harvesting (in step 2 of the 3.6 plan), or
not, we'll have to figure that out.

- Doug Way