I can only speak for myself, but I suspect there are others who basically support what you're saying Doug and at the same time like to see a stronger committment from the board towards achieving "this level of modularity". I had said that I didn't support Juan's proposal "as is" because it didn't acknowledge the factors you've addressed. What do I mean by "stronger committment"? I have an idea, but I'm not 100% sure because I think it depends in part on some factors which are not clear to me:


-The Board position on interacting with the major code forks
-The Board's committment to Spoon.
-Last but most significant in my view, is the Board's position on Squeak kernel ownership which I discussed in another post.

Cheers,

Laurence

On 11/2/06, Doug Way <dway@mailcan.com> wrote:
I support Juan's proposal and Goran's comments.

On Nov 1, 2006, at 1:51 PM, J J wrote:
>
> I guess I also missed the part where what Juan is doing means that
> squeak dumps EToys.  Can't it just be a different image like the
> dev image?  I don't think that means a fork, per se. ...

Right.  It's not necessarily a fork, although it could end up being a
fork.

With Juan's proposal, EToys would be removed from the 3.10alpha
"basic" image which follows the update stream.  (For better or worse,
it looks like the update stream will still be needed for the next
release at least.)

This doesn't mean EToys will never work with the squeak-dev 3.10 and
beyond images... Ideally, someone would create the loadable EToys
package for 3.10 and it would be part of the 3.10 "full" image.

I'd think it wouldn't be *that* hard to make a loadable EToys package
for 3.9... it's non-trivial, but I'd think it'd at least be no more
difficult than the unloading work Juan has already done.  (Any
comments on that, Juan?)  It is possible, though, that no one will do
it.  And I certainly wouldn't expect Juan to do it, for example.

If a 3.9 EToys package is created, the 3.10 EToys package would be
created from that, adjusting for any Morphic changes from 3.9 to
3.10.  (Or even better, it would be ported from the latest OLPC
version, although that would be a bigger merge.)
 
In any case, this sort of basic level of modularity is essential for
the survival of the squeak-dev image into the future, and for the
community to grow, IMHO.  This sort of disentangling has various
other benefits such as getting us closer to working on top of Spoon.

- Doug