[Squeakfoundation]Re: [KCP] is looking for reviewers

[Stephane Ducasse]

Hi


I send the email to the foundation because I think that my proposal at 
the end is important and will save us a lot of broken code and 
frustration.
The beginning of the email is about how to deal with KCP produced in 
3.5 that break at load time
because of removed classes in 3.6.

> When you say "produce new changesets", you mean you want to upgrade 
> your 3.4-based KCP changesets so that they work with the current 
> 3.6alpha-5247?

Yes and I think that this is not the right way to do it because we 
always followed a add only stream.


>
>> What is your  idea of an efficient way to do that? Somebody will have 
>> to do the dirty  work so what is your point of view.
>
> The only thing I would suggest is using the ConflictChecker thingy, 
> which helps somewhat.  Using it will not necessarily catch *all* 
> possible conflict problems, but it will catch the direct method 
> conflicts, which are probably 90% of the problems you would see.  This 
> is typically "good enough", and then we can put it into the merged 
> changes into the update stream and let people find any remaining bugs.

OK I will try to use it, but right now I'm the only one doing KCP so if 
I have to check too much nothing will happen.
Sad but true.
>
> Let me know if you need any help using the ConflictChecker, or if you 
> have suggestions for improvements.
>
> Hopefully there are not a *large* number of conflicts that you will 
> see.  Unfortunately, when we have KCP and MCP and other people making 
> large changes all at the same time, some conflicts are unavoidable.  
> But of course better factoring will reduce the probability of 
> conflicts in the future.
>
> The other issue that comes up is that these KCP/MCP changes often 
> require changes to be made in the packages which were recently removed 
> (SUnit, Celeste, etc.), and I'm not sure these packages are getting 
> updated properly right now... this is a more general problem.  (Some 
> way to broadcast desired changes to the package owners might be 
> interesting.)

May be the trick would be to have dummy classes for each removed 
packages (note that this implies that we have an object representing 
package which should not be that difficult and that we will have to 
have. The problem I see is that when a package changes and we do not 
know what are the classes of this package in the image then there is no 
way that we can
identify where the changes should go) and then we load 3.5 fixes then 
we collect the changes related to each package and republish it.

Now if we work only in 3.6 and do not care about removed stuff, we will 
create a lot of broken code. I have the impression that the easiest and 
safest solution would be to load **all** the removals in 3.6 (this 
means all the stuff you think should be in 3.6 full image) and always 
do the changes regarding this configuration, then the removal are 
removed. Because we are trying to do two things at the same times and 
we are too few.

So let us know what you think about that.
Stef
>
> - Doug
>
>