Squeak Roadmap ...

stephane ducasse stephane.ducasse at free.fr
Thu Sep 20 18:30:02 UTC 2007


for squeak 3.11 or 4.0 I would like to see implemented the roadmap I  
sent for 3.10.

Now it is also important to learn from the failure of VisualWorks new  
UI: they tried revolution and failed
ow they are following evolution: ie instead of continuing to write a  
brand new framework they are
improving the existing one: now my take for squeak would be
	- clean Morphic (remove borken code, class referencing subclasses,  
favor instance variable access over dictionary use)
	- make sure that a new framework like Morphic3 or xxx could be loaded
	- check out Sophie code that could be packaged and used for Squeak.

Stef

It was and now I would add be based on pavel mini image + more tests  
and repackaging at the package level.

Here are the main actions I would like to see happening:

	- be able to load Tweak

	- be able to load Sophie infrastructural elements (ressource  
location...)
	=> even substitute current Squeak ones with sophie ones (Rome renderer)

	- curve/remove Etoy/projects (without having to reload them)

	- remove nebraska and others/ remove packages early in the process

	- new compile method format if available else klaus fix for source  
limits

	- may be newcompiler if ready

	- aggressive cleans in a lot of areas

	- look at Pavel overrides problems
	=> ideally be able to use Pavel image as a basis for 10/4

	- Use tool builder (looking at the tool plus) and change the current  
tools
	(the ones that deserve migration)

	- more tests

	- may be using MC2 if ready

	- better integration of AST and refactoring support

So if you want to help there on a regular basis or on specific items  
please say it

Stef




> On 9/19/07, GeertC <geert.wl.claes at gmail.com> wrote:
> What does the roadmap look like for the Squeak core image (the one  
> downloaded
> from www.squeak.org)?
>
> As far as I've been able to tell, the roadmap looks like:
> * The current release team will continue to correct bugs in Squeak  
> as reported until they have decided they are done, they are  
> exhausted, they are told to stop, or someone comes up with a new  
> plan for version 3.11 / 4.0.
> *  The next step in the roadmap is based on someone coming up with  
> what they want to do next, proposing it, and getting it accepted by  
> the board.  (Ideally more than 1 group would come up with an idea  
> they would be willing to undertake, and the board could chose  
> between them).  They then start the next relase.
> *  This continues until we as a community decide to do it some  
> other way.
>
> The Board (or at least members of the board) have stated that they  
> weren't elected to decide where Squeak was going technically, but  
> rather to handle other issues such as the legal formation of the  
> community and other non-technical issues.  This doesn't have to be  
> this way - and we can choose to make that change at the next  
> election if we want too - and demand it during the election.  Or,  
> someone could propose another structure for technical direction -  
> maybe have the board appoint a 'temporary technical dictator' that  
> holds the title until that person is removed from office by that  
> (or a later) board.
>
> If you like that roadmap that you proposed and you can find some  
> like-minded individuals that would like to work on that for the  
> next release AND you have the time and dedication to follow through  
> on it, then a great next step would be to start aggitating for the  
> next release cycle to be those goals.  Come up with a proposal (I  
> think that mainly means specific goals, rough dates, and a team  
> roster, maybe other stuff - I haven't actually read any of the  
> previous ones) and forward it to the board and/or list for  
> discussion.  If it is accepted, negotiate with the current release  
> team about their completion date and when you are going to start.
>
> At least, this is my interpretation of how these things are  
> currently being handled.  I'd be happy to be corrected wherever  
> necessary.
>
> -Chris
>
>
>




More information about the Squeak-dev mailing list