[UPDATES] 4 more for 3.6alpha

Stephane Ducasse ducasse at iam.unibe.ch
Wed Apr 16 06:25:40 UTC 2003


But doug

the problem is not about conflicts it is about call inside the methods 
that have to be changed. Is your tool checking that? I do not think so. 
So sure we can take go over all the deprecated methods and check if 
they have been called from within the
removals but I do not believe that it will be simple and that we will 
have the resources to that alone.


> 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.

Sorry I'm confused. How our changeset can be smaller than two to three 
methods?


> (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.

But at the end this means that we will have to reproduce the removals 
and this is difficult for us because we do not know their logic.

>
> 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.


I'm afraid that we are trying to do too much in the same time removals 
and cleaning.
I think that making major cleaning first and removal after would be 
easier for everybody because working on a closed world assumption is 
easier and then we can chop it. While now we will have to analysed the 
chopped parts and see how the cleaning impact them.

Just have a look at the browse method removed from Behavior to evaluate 
how this is
touching all the browsers for example. The changes are trivial but the 
methods have to be manually edited.

Stef


>
> - Doug Way
>
>
Prof. Dr. Stéphane DUCASSE
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do 
different? ...  especially if,
  by doing something different, today might not be your last day on 
earth" Calvin&Hobbes

"The best way to predict the future is to invent it..." Alan Kay.

Open Source Smalltalks: http://www.squeak.org, 
http://www.gnu.org/software/smalltalk/smalltalk.html
Free books for Universities at 
http://www.esug.org/sponsoring/promotionProgram.html
Free Online Book at 
http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html



More information about the Squeak-dev mailing list