Hi all!

So, the report 1 is out and we now want to discuss and finalize Stefs
(and crew) roadmap for Squeak 3.9 according to the postings a while back
from Stephane and crew. I include below those two postings verbatim. The
only thing in the report that affects this is that we want the
ToolBuilder package into 3.9.

Let's take a look at this yet again and come to a concluded roadmap
within say a week or so. I am now going to take weekend and will
probably not be very active until monday. But this todo is on me: 
	http://anakin.bluefish.se/castaways/1

...and I will make sure to vaccum clean this thread and gather the
discussion into a proposal during next week. So if you make your voice
heard it will definitely have an effect. Just try to keep the postings
clear and showing what you support and not - otherwise it will be hard
to turn it into some sort of result.

So, let's all take a good look here and discuss these bits. Then we will
post a concrete proposal based on all that (trying to reflect the
general concensus) and take some last feedback and then we decide it.

regards, Göran

PS. Perhaps our "take" on this roadmap would have been interesting but
frankly - we don't have time for that now. Remember, we aren't going to
push stuff down your throats - let's discuss it alltogether, just like
we always do and take it from there.

-------------
Hi all,

<WARNING>
Please before replying to this email ask yourself what you did recently 
for squeak besides sending emails!
And as you will see there are a lot of places where you can contribute.
</WARNING>

So after a long discussion with the crew here (nathanael, alex, marcus 
and adrian will agree)
we decided not to fork and this will cost us energy and time. But we 
think that this is worth.

We plan to do the following: we will focus on building 3.9 and take our 
time and your feedback to do it. We think that april/mai would be a 
good release date so that we have the time to test and work in pace.
(Note also that this will be my last contribution to the community 
(from today perspective since I do not
know where I will living in 5 months from now). So we want to have a 
really cool 3.9.)
BUT BUT BUT we will only focus on what we are good at and we NEED the 
help of other people to work on the
other areas: UI, Morph (PLM), Etoy,

Note that the list after is not fixed since we do not want to push 
something that will not be ready. For example,
we will pay an extreme attention that the traits are fully integrated. 
Nathanael is planning to help and also
would like to for example make sure that he can refactor the collection 
hierarchy before releasing traits.

We are LOOKING for a lead harvester, and ETOY harvester and a 
Multimedia one.

3.9 Full

	- new multimedia app (Ogg reader?)
	- YAXO (p) a real one on SqueakSource :) (yes this is a subliminal 
message :))
	- Wonderland back in shape (you see mark there are room) / 3DBalloon
	- and anything that is valuable for full
	- GENIE (yes ned we want that)
	- Connectors (yes yes we want that too)
	-> ned would it be possible to get access to one your recent Genie 
image?
	- but people will have to provide package in MC format (or at least a 
good sar)
	

3.9 Basic (the stuff for the developer: not the mini image! )
	- Diego look
	- eCompletion or another package (p)
	- keybinding cool package (may this one should go in basic as package 
(p) because the current way of binding
	key is system wide and not really good)
	- shout (p)
	- SqueakMap II (yes we want it)
	- rbengine (p) this is absolutely not intrusive (ok there are some 
duplicated functionality but we need it
	and if a brave soul wants to optimize it will be really possible for 
now we should not be that warry since the package is 	self-contained 
and we are not enough, so we should be productive and then after one 
guy will fix that if necessary). So 	simply a package that can be 
removed but that is needed to code.
	- services
	- new preferences pane
	- traits
	- new compiler framework (note that according to Scott this should not 
have an impact on etoy)
	But again we need a Etoy expert to help.
	- refactoring of systemDictionary as proposed to get it done once 
right. Again read again what we wrote and
	comment. (I think that having SmallltalkImage and SystemDictionary 
does not make sense to have both)
	- OB (p?) + browseUnit new version (integrated version). The idea of 
having OB here is that we want to enable
	the creation of new tools and deprecate slowly the use of the old 
browser (which could be packaged but keep
	alive in case we only want to have one single but gigantic class).
	- MC in the base image (we all would like to have a mini image and a 
cool script but for now
	not having MC in the base image is getting in our way to maintain 
packages and to also produce a much
	smaller mini-image, to also learn what we cannot do with MC and ask 
kindly to MC developers if they
	can fix the problems we see). Except if of course someone come up with 
a better idea and code
	to support that. We would like to avoid to abandon the idea of having 
packages in basic since we would like
	to push further the packages curving process.

	- We would like also to have a much better support for packages:
	Package as real entities with support for
		- resources
		- meta information
		- comments
		- substituing package info
	(alex is willing to work on that).

We also like the idea of TestServer, so feel free to write tests! May 
be markus G could be the guy responsible to
push them into the stream. Markus? Romain?

Note that for the packages marked as (p) of course we will ask if the 
package creator is willing to help
and feel the pression of having his cool package in Basic. One 
requirement could be that the code is managed
with MC and SqueakSource so that in case of emergency we can get our 
hands on it :)
We ask for feedback, help, testing, ideas....	

BUT MORE IMPORTANT:
This community needs to structure itself. We would like to be able to 
pay someone to work half-time on harvesting
and improving the system. So we are looking for solutions. Would you be 
ready to pay for a cool Squeak release?
Do not reply to this question now, just look at yourself in the mirror 
and let us hope that something happen.

Stef, alex, marcs, adrian and nathanael
(writing style of Stef ;)))

PS: marcus got totally burnt by the harvesting process and the lack of 
communication so now he should
reenergize himself. So don't expect anything from him, because he is 
learning to say no :)))

	


	From: 	  ducasse at iam.unibe.ch
	Subject: 	A roadmap for 3.9
	Date: 	9 décembre 2004 13:38:44 GMT+01:00
	To: 	  squeak-dev at lists.squeakfoundation.org
	Reply-To: 	  squeak-dev at lists.squeakfoundation.org

hi all

I have been discussing with marcus/alex and also thinking about that 
after my remarks on andreas remarks related to
changes, interfaces/ cleaning vs changes. So to avoid get frustration 
from all the parts and to state clearly what is our
plan for 3.9 we would like you to read the following and let us know. 
Depending on the reactions, we (the guys from berne) may decide to 
produce our own stream, because we must work too ;). But we understand 
that other people cannot deal with a system changing. But in that case 
we should draw the consequences.

Our part that we will work on for 3.9 is to get the system improved 
from a developers point of view. We
think that having a good foundation is important for everybody.

The overall idea is to slowly improve one aspect of Squeak: The idea to 
have a System to build the next
System with.

This has lots of consquences, one is that you want the system to be in 
a shape that e.g., students that are not yet
complete Squeak experts can start to do experiments with it on a quite 
deep level, e.g., change the compiler or
add a feature to the Browser.  Another aspect is to have a System for 
research. The Traits project has been hugely
successful, but it has shown that Squeak does have real problems if you 
use it for stuff like that. If Squeak is supposed
to be the system of choice for research like this, we need to fix those 
problems, we need to make sure that the
lessons learned from those projects get fed back into the system. (One 
example is the change-notification that was added to 3.7, it is a 
direct result of the Traits project)

All this does not mean that 3.9 will only be about that stuff: We 
surely want to see e.g. the work of Diego beeing
included, also any changes that other people would need are welcome.

For our perspective here what we would like to have: we put in (p) the 
code that  will be in external packages,
which likely will be "full".

	- services
	- new preferences pane
	- OB (p?) + browseUnit new version
	- MC in the base image
	- rbengine (p)
	- shout (p)
	- SqueakMap II (yes we want it)
	- eCompletion or another package
	- keybinding
	- traits
	- new compiler framework of anthony adapted by marcus to produce
	not full block. Note that for Etoy the old compiler will still be in 
the image so from that point of view
	it should not have an impact.
	- refactoring of systemDictionary. (see below this point)

We are sure that we forgot something but this is what we have on top of 
my head.

Now for systemDictionary here is the situation and here is where we 
would like to be after 3.9

In the past we created SmalltalkImage out of SystemDictionary in the 
hope to have SystemDictionary be a nice
and simple namespace class. Lot of stuff has been put in coherent 
places (SystemNavigation, SpaceTally, Changeset....)
But this will not work since people get used to add stuff there and 
Smalltalk is a cool name.
So the new proposal is the following one and is partly implemented. 
Note however that it will require
from us a lot of work so if you are against it please say it and we 
will only do it for us.

from a user point of view we want to have:
	only one class: SmalltalkImage/SystDict for all the image related 
services
	(VM pluggins, ....) but the namespace behavior will be delegated to 
Namespace.

        All the previous code referencing Smalltalk will work but with 
deprecation for the namespace interface.

 From the language programmer point of view:
	there will be a namespace that can be used for experimentation
	this class will replace the environment class of dan that is now 
obsolete

We plan to proceed that way:
	- create a class namespace with a new interface (done)
	- delegate from systemDictionary to this new class (done but not 
published)
	- deprecate all the namespace method of systemDictionary (but we 
likely want to keep them for some time)
	- fix all the in image senders of Smalltalk as a namespace to use the 
new class (using self environment for example).
	(partly done over the previous years)
	- merge back SmalltalkImage into SystemDictionary: the idea here is to 
not have SystemDict as a subclass of Dictionary
	- have Smalltalk pointing to an instance of this new entity, so that 
everybody is happy.



Stef and Marcus