Hi all!

=?ISO-8859-1?Q?st=E9phane_ducasse?= <ducasse at iam.unibe.ch> wrote:
> Hi all,
> 
> <WARNING>
> Please before replying to this email ask yourself what you did recently 
> for squeak besides sending emails!

Eh... :)

> And as you will see there are a lot of places where you can contribute.
> </WARNING>

Indeed.

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

Thank god. I haven't been able to catch up in full but I am grateful as
HELL you didn't elect to fork.
Even though I can appreciate the frustration. But let's all chip in and
get Squeak in shape instead. And I don't only mean the artifact. We need
to work on our processes also. As an example - a small such thing is for
example the bi-monthly report I just started. :)

Anyway, some feedback:

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

Sounds reasonable.

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

Great news!

> Nathanael is planning to help and also
> would like to for example make sure that he can refactor the collection 
> hierarchy before releasing traits.

Again, sounds great. And... when this work is about to start (the
Collection refactoring) - Nathanael - please ask the list for interested
parties - I know there are a few people who have volunteered to be
stewards for Collections earlier - we don't want to drop that ball, ok?

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

Yes, someone for eToys will just have to step up or it will surely rot.
That is just a plain fact. Michael?

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

At the moment I have no good comments for Full - except that Connectors
would be sweet and yes - MC is definitely the format we want.

I can help out with the 3.9 Full script btw, being the SM-dude and all.

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

Yes, of course my ball. :)

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

Is Colin up for OB here? I sure hope so and yes - going for OB would be
a good step forward indeed.

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

Since I like MC a LOT and I also highly advocate its addition into Basic
- I could sign up to a look at building a Minimal-script if that would
make people more eager to accept MC into Basic. Remember - Basic is not
Minimal.

Again, also remember folks - these are proper packages - they should be
easy to remove since they are easy to add. :)
 
> 	- 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).

Now... this is an area where I get a bit nervous. It seems like you are
describing SM and.... well, I want more clarification. IMHO SMPackage is
a "real entity" and it already has lots of this. Alex - please post or
email in private and explain. I don't want us to reinvent SM.

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

MC yes - SqueakSource, well - I haven't used it myself yet so... is it
necessary? Seems like a public MC repo would be sufficient as a
requirement.

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


I agree - we need to take some drastic measurements regarding our
"structure". Or our processes. One such step is my addition of the
bi-monthly report. It may sound like a very silly thing but when you
realize that I intend to include decisions in the report, it should be
obvious that it can turn into our primary tool for making sure people
know what is being decided and who is doing what.

It will turn the report editor into a person who "detects" what
decisions are being made and puts that into print. As I said - I will
start by being that person.

regards, Göran

PS. Might try to put out the first issue sooner to kickstart it.