Squeak Roadmap ...

Philippe Marschall philippe.marschall at gmail.com
Fri Sep 21 09:25:29 UTC 2007


2007/9/20, stephane ducasse <stephane.ducasse at free.fr>:
> 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

They didn't fail. They had a working product with people using it to
build stuff. They just decided to not ship it.

Cheers
Philippe

> 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