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
squeakfoundation@lists.squeakfoundation.org