RE: 3.4 release

> I haven't seen any posts recently from Andreas either.

Not surprising - I've been travelling the last two weeks and just got back
home yesterday after having a really great time in L.A. (I always wonder why
people go there in the summer - jan/feb is the _perfect_ time to be there)
as well as Japan (which reminds me - we need to get this multi-lingual
support of Yoshiki integrated some time soon; I've seen some beautiful stuff
being done in both Japanese and Korean and there was some real interest from
Chinese guys as well).

> I agree to all said. Sounds good. By the way, how is Andreas and the
> Croquet guys doing? Are there lots of work being done there that is
> essentially getting forked now?

That kinda depends on your definition of "forking". As it is, there are a
few modifications to BitBlt and float array primitives which are essential
for Croquet but those had been posted to 3.3alpha and I am reasonably sure
they were forwarded to 3.4 (though I have to double check on them).

Tim wrote:
> Any additions that are only in the croquet image really ought
> to have been cross ported before now in order to let a decent testing
> period elapse.

So what's the process for this? Let's assume we need another addition to
BitBlt or (more likely) to some of the primitive float operations.
"Cross-porting" these is a no-op (since it only implies a few primitive
methods) but how you would do "decent testing" outside of Croquet eludes me
somewhat ;-)

Doug wrote:
> - Should we wait a few days between steps 1 and 2?  This would let 
> people test the final image a bit just to make sure there wasn't some 
> major problem, and maybe check out any final cosmetic tweaks.  Also, it 
> would give the VM maintainers a few days to get their VMs ready.  But 
> perhaps this isn't necessary... maybe we should make sure the VMs are 
> ready before we declare 3.4 final.  (Certainly they should be almost 
> ready anyway.)

I'd recommend waiting a few days in order for the VM maintainers to have
"interim builds" which ought to be just tests if there are any major
problems. Ultimately, the "final VMs" should be build from the release since
that'll make sure that people using the X.Y VM have a chance of recreating
_exactly_ the version that they're using (important if you ever have to
debug something).

Tim wrote:
> Nathanael said (on his Traits download page) that the ClassBuilder was 
> broken in the 3.4 image. I just asked him to clarify. Do we know 
> what's broken?

See my recent message to Squeak-Dev. The problem is that full recompilation
of the entire class hierarchy chokes on Metaclass for reasons outlined in
that message. BTW, this is the _only_ problem with it - everything else
works just beautifully and is much more robust and simpler than it used to
be. And as a matter of fact I am pretty certain that none of the previous
versions handled the recompilation of the entire meta class hierarchy
correctly (cf. the note on creating a new Metaclass).

Doug replied:
> ... but I s'pose if a fix comes along which appears straightforward,
> we could possibly include it.

Any fix to this problem is likely to be trivial if thought through but
thinking these issues through is far from trivial. One should also note that
adding instance variables to Behavior/ClassDescription/Class etc. is nothing
you do regularly so I don't consider this problem to be critical.

Cheers,
  - Andreas