Team proposal: Morphic Splitters

Cees de Groot cg at cdegroot.com
Wed Feb 23 11:11:33 UTC 2005


Hi All,

After the deafening silence on our plans, I take it you all agree with it  
but are just to shy to speak up in public ;)

Anyway, here's a team proposal. I'm Team Leader Ad Interim - if someone  
else wants the job, there's a good chance I'll step down because I'll be  
busy enough as it is.

Goal: split up Morphic into 'Mini Morphic' and 'Rest Of Morphic'

Timeline: June/July

Acknowledgements: Avi and Dan, I think.

Details:

Morphic has grown a bit big and ugly. This has had various reasons, all  
probably very good design decisions at the time they were made, but it's  
about time to clean up this legacy.

A very big part of Morphic is 'just' there to support eToys (let me stress  
that we squeak-dev'ers are a minority user group!). We're lugging it with  
us, trying to keep it in shape, but we hardly use it. Also, because  
Morphic+eToys has grown such a big thing it is nigh impossible to clean it  
up. So, the immediate plan is to untangle this Gordian Knot - we have one  
handicap that Alexander didn't have: swords are not allowed ;)

The MINIMAL deliverable of this project is:
- CoreMorphic package. World/project support + the UI bits for ToolBuilder  
to operate.
- FatMorphic package. All the rest of it.
- eToys package.
These packages should all be loadable/unloadable on demand. We'd like  
Squeak to become UI-neutral, so it must become simple to swap Morphic for  
MVC or vice versa (or for Tweak, wxSqueak, ...).

CONDITIONS:
- The community accepts that if this team is instated AND delivers at  
least the minimal deliverables, these deliverables will become part of the  
next release of Squeak after delivery.

OPTIONAL deliverables:
- While we're at it, make MVC a loadable/unloadable package;
- Refactoring. Cutting out dead wood from especially FatMorphic that's not  
needed;
- Further splitups of FatMorphic, if it turns out to be logical.

DEPENDENCIES:
- We use ToolBuilder to define what CoreMorphic is. I.e., whatever  
ToolBuilder needs, lands in CoreMorphic. Whatever ToolBuilder does not  
need, does not land into CoreMorphic. The project assumes that ToolBuilder  
will be in the image that will be used to release the Team's deliverables.

NON-DEPENDENCIES:
- We are not going to assume that any output from any package/modules team  
is ready in time. So straight PackageInfo is our basis.

I repeat that a conditio sine qua non for this project is that eToys  
becomes loadable/unloadable and keeps working. So it's not a matter, as  
the 'strippers' do, of just cutting off the excess fat; it needs to be  
carefully trimmed of and kept apart. Which makes it a job not much more  
glorious than Ken's 'Janitors' Team ;). After we've delivered, the idea is  
to have people sign up for maintenance of these various packages, where my  
expectation is that the Squeaklanders will start taking care of the eToys  
package.

Joining:

Announce here on the list or through private mail to me. When no  
objections from the community arise and there are enough people that join  
up, I'll ask my colleague coordinators to declare it as a Team and setup  
list+swiki+MC storage. If you want to become the Team leader for this,  
please drop me a mail with motivation etcetera.

Regards,

Cees





More information about the Squeak-dev mailing list