Assuming I'll still be the one harvesting KCP work (as I proposed), that
will happen starting in May. Anyhow, I propose to continue with the
removals, and where they conflict with KCP updates, we'll just have to
update the packages. Note that since most install packages for the
removals have already been created, there is no way we can avoid this
work anyway, really.

Daniel

Doug Way <dway at riskmetrics.com> wrote:
> 
> 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