Hi all!

(sorry, this one is also long - but Stefs damn roadmap was long so...
:))

Hehe, the silence is thundering. Well, to get things started here are
some proposals about 3.9:

- We set the release date to late june. That would at least fit
Squeakland I have been told by Michael Rueger, for their summer release
in july. Don't know what other stakeholders think, and we could check
that. This would give us... 3.5 months?

- We start using release Teams. 3.8 used this (Michael Rueger and gang),
and I think it is a very good thing. A Team focused on the release
itself, and then after release, it is ended. This is typically about
update stream management, decisions, goals, freezing etc. You know -
release management! :) And of course help everything along and follow
up.

- With 3.9 we should start distributing Minimal as well as Basic and
Full. Otherwise we will have trouble adding "nice" packages to Basic,
because some people inevitably will not want them. See for example Shout
or eCompletion below. Either that, or we have to make packages
uninstallable. But I think it is good if we start to materialize Minimal
- the current approach of letting Basic be the target of the update
stream, and not distributing Minimal is confusing to say the least. Even
confusing to us who actually should know how this stuff fits together.
;)

- ToolBuilder, as we said, we really think that ToolBuilder should be in
3.9 - Minimal or Basic (?). No Team leader assigned to make this real
yet, but Avi Bryant and Brian Brown have been asked at least, but Avi is
in Venice right now. :)


...and here are my *PERSONAL* shoot-from-the-hip thoughts about the
stuff in "Stefs roadmap" (if not else my outrageous thoughts might get
*someone* to react at least):

> 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.

Good, then late june is ok too I guess. :)

> 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. 

Does that mean "as a package" (Traits)? Or is it too invasive to have as
a package? I like Traits but we need to make it clear what it will mean.

Or in other words - you guys need to explain to us how utterly
wonderful, backwards compatible and non-disturbing Traits is so that
*everyone* ought to want to embrace it. :)

If it can still be a separate addon package - then the story is of
course much different.

> 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.

Yeah, these things are still open more or less. Now perhaps today we are
talking about Teams, but it is essentially the same thing - someone
willing.

> 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)

Just so all know - Wonderland (Balloon3D) is today an orphaned package:
	http://map1.squeakfoundation.org/sm/packagebyname/balloon3d

Connectors is very cool, might be a good thing to have in Full. The rest
I know little about and don't have an opinion on. Well, YAXO seems like
an odd package to suggest for Full - reason?

> 3.9 Basic (the stuff for the developer: not the mini image! )
> 	- Diego look

Already in AFAIK. But needs some work.

> 	- eCompletion or another package (p)

Yes, think so. As described in the beginning of my post - if people
don't like it, they can use Minimal and then install only what they
want.

> 	- 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)

Dunno. Is it a good thing? :)

> 	- shout (p)

Shout is wonderful. Some people may have a problem with it being slow -
but it sure is a huge step forward for us developers. Same thing here -
including Shout in Basic implies that we need to distribute Minimal, or
else Tim and other users with dog slow machines will get royally
annoyed. :)

Either that or make sure Shout screams (couldn't help the pun).

> 	- SqueakMap II (yes we want it)

Yup, a new release - with whatever that means. Dependencies for sure.

> 	- 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.

Ok... did not follow exactly, RB is not my alley - but this is the
ballpark of the Berne Guys - so I trust their judgement.

> 	- services
> 	- new preferences pane

Both those sound fine.

> 	- traits

Ah. This one is more controversial. AFAIK the community hasn't "decided"
on Traits.

I personally think, without having seen the latest incarnation, it is a
neat technique. But if this is not a package (that you can then avoid
using) then we need much more info on what it means before we can
decide. And Martin Wirblat's view is in many regards shared by me - even
though I want to hear more first. I personally do not belong to the
Keep-Squeak-Being-Smalltalk-80-Forever-Faction (not implying Martin does
either). :)

Can we get a presentation on the exact effects and predicted
benefits/problems solved on introducing 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.

Need more info then. But if Scott is right, then go go. :)

> 	- 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)

Ok - this is the stuff described better below.

> 	- 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).

This is good stuff. OB is a great thing, and yes, remolding the old
stuff so that it can be easily thrown out (he, that sounded easy,
right?!) would also be nice. Would like to hear Colin about it.

> 	- 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.

I agree with having Monticello in Basic - as long as we start
distributing Minimal.
Not sure if I am missing some logic there, but I think that is what I
think. :)

> 	- 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).

There was recently code posted by Alexandre and I want the new proposed
"Packages" Team to look at it the Very First Thing we do. Haven't had
time to look yet.
 
> 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?

Doesn't sound like something we need to decide for 3.9 (test server), I
like the idea too.

> 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 :)

Yes. Agree.

> We ask for feedback, help, testing, ideas....	

And now finally you got some feedback. :)
And then from the second posting I think this was the only thing not
mentioned yet:

> 	- 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.

Ok, fine.

And then about SystemDictionary:

> 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.

Ok, so the idea is to let "Smalltalk" be the kitchen-sink but move the
actual dictionary part of it to "Namespace", correct?

>  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)

Which makes it still backwards compatible I guess.

> 	- 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

Ok, so no more SmalltalkImage? And what about SystemNavigation? We keep
that as is?

> 	- have Smalltalk pointing to an instance of this new entity, so that 
> everybody is happy.

Ok, I *think* I like this, unless someone can show arguments to the
contrary.
Just as long as we follow through on it.

> Stef and Marcus

regards, Göran

PS. We can of course chop this up in multiple threads when discussing.
We will try to distill the discussion into some kind of table as we go.
Or better yet, the release Team for 3.9 should take that ball - now...
who is ready to take on being release Master for 3.9?!