They didn't fail. They had a working product with people using it to
build stuff. They just decided to not ship it.
> 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 <
[hidden email]> 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
> >
> >
> >
>
>
>
Locked
Picture 1.jpg (40K)