<div dir="ltr">Hi David,<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 20, 2014 at 6:35 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Oct 16, 2014 at 11:51:20PM -0700, Eliot Miranda wrote:<br>
> Hi All,<br>
><br>
> finally the Spur Squeak trunk image is updateable.<br>
<br>
</span>Yay!<br>
<span class=""><br>
> The issue<br>
> is of course that we have this tricky package situation to manage where, to<br>
> keep the two systems in sync, modifications to Collections, Compiler,<br>
> Kernel and System need to be committed from V3 and auto-edited to Spur. I<br>
> think that's too clumsy to be practicable.<br>
<br>
</span>When I look at the Spur related changes to these four large packages, it seems<br>
to me that we might be able to reduce the scope of the problem by moving the<br>
parts that require changes into separate packages or sub-packages. The portions<br>
of these packages that need to change are not insignificant, but if they were<br>
contained within well defined package boundaries, they might become simpler<br>
to manage.<br>
<br>
To illustrate: The changes in the Collections package are almost entirely<br>
related to class Character, whose instances are immediate in the Spur format.<br>
It might make very good sense if the methods directly related to immediateness<br>
of a character were localized in a package where they can be maintained<br>
independently of all the other Collections classes and methods.<br>
<br>
Looking at it from another angle, the Kernel package is arguably too large, and<br>
if I want to make changes to Kernel-Chronology (as I have recently been doing<br>
with UTCDateAndTime <<a href="http://wiki.squeak.org/squeak/6197" target="_blank">http://wiki.squeak.org/squeak/6197</a>> just as an example),<br>
then I have problems if I want to coordinate that external package with Squeak<br>
trunk. If I also want to coordinate my little project with all the updates<br>
required for both Kernel and Kernel.spur, the situation becomes impossible.<br>
<br>
I apologize in advance because I have not really thought this through in<br>
detail, but it seems to me that a bit of pragmatic reorganization of our<br>
package structure might make the Spur transition a lot easier to manage.<br>
<br>
I note that in the past we have put energy into reorganizing our package<br>
structures in the interest of making the image more modular. That is important,<br>
but managing the transition to Spur is even more important. If improving the<br>
package structure could make this easier, then we should make it a priority.<br></blockquote><div><br></div><div>While I'm happy to see packages decomposed I've chosen the approach to changing the four relevant packages Spur modifies for good reason. Essentially once we move to Spur I don't want there to be artifacts present which are simply to do with the change to Spur. So keeping Collections, Compiler, Kernel and System whole but in Spur-specific branches allows us to keep the system looking the same once we release it. Further, all the support for branching and editing these packages is now working and I'm really not keep on putting more effort into it to complicate it further. I've got lots of other things to do. So now that Spur works and is nearly ready for release can we let it be?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Perhaps allowing the two<br>
> systems to fork and doing a manual merge will be acceptable, but it'll be<br>
> work to keep them in sync.<br>
<br>
</span>I agree. I also think that this kind of maintenance work is not enjoyable,<br>
and is not likely to be kept up on an ongoing basis. So we need to think<br>
of ways for the path forward to be A) enjoyable or B) not too much work or<br>
C) all of the above :-)<br></blockquote><div> </div><div>Well, we should discuss what the release criteria are at the next board meeting. We may be able to release before the end of the year, which would be great.</div></div><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>