On Mon, Oct 20, 2014 at 07:18:14PM -0700, Eliot Miranda wrote:
> Hi David,
> 
> On Mon, Oct 20, 2014 at 6:35 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> > On Thu, Oct 16, 2014 at 11:51:20PM -0700, Eliot Miranda wrote:
> > > Hi All,
> > >
> > >     finally the Spur Squeak trunk image is updateable.
> >
> > Yay!
> >
> > > The issue
> > > is of course that we have this tricky package situation to manage where,
> > to
> > > keep the two systems in sync, modifications to Collections, Compiler,
> > > Kernel and System need to be committed from V3 and auto-edited to Spur. I
> > > think that's too clumsy to be practicable.
> >
> > When I look at the Spur related changes to these four large packages, it
> > seems
> > to me that we might be able to reduce the scope of the problem by moving
> > the
> > parts that require changes into separate packages or sub-packages. The
> > portions
> > of these packages that need to change are not insignificant, but if they
> > were
> > contained within well defined package boundaries, they might become simpler
> > to manage.
> >
> > To illustrate: The changes in the Collections package are almost entirely
> > related to class Character, whose instances are immediate in the Spur
> > format.
> > It might make very good sense if the methods directly related to
> > immediateness
> > of a character were localized in a package where they can be maintained
> > independently of all the other Collections classes and methods.
> >
> > Looking at it from another angle, the Kernel package is arguably too
> > large, and
> > if I want to make changes to Kernel-Chronology (as I have recently been
> > doing
> > with UTCDateAndTime <http://wiki.squeak.org/squeak/6197> just as an
> > example),
> > then I have problems if I want to coordinate that external package with
> > Squeak
> > trunk.  If I also want to coordinate my little project with all the updates
> > required for both Kernel and Kernel.spur, the situation becomes impossible.
> >
> > I apologize in advance because I have not really thought this through in
> > detail, but it seems to me that a bit of pragmatic reorganization of our
> > package structure might make the Spur transition a lot easier to manage.
> >
> > I note that in the past we have put energy into reorganizing our package
> > structures in the interest of making the image more modular. That is
> > important,
> > but managing the transition to Spur is even more important. If improving
> > the
> > package structure could make this easier, then we should make it a
> > priority.
> >
> 
> 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?
> 

Yes, for sure. If it does not make things easier, let's not do it.

> 
> > >  Perhaps allowing the two
> > > systems to fork and doing a manual merge will be acceptable, but it'll be
> > > work to keep them in sync.
> >
> > I agree. I also think that this kind of maintenance work is not enjoyable,
> > and is not likely to be kept up on an ongoing basis. So we need to think
> > of ways for the path forward to be A) enjoyable or B) not too much work or
> > C) all of the above :-)
> >
> 
> 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.
> 

Ok, good.

Dave