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
|