Hi lex

I do not disagree with you: :) this is not that we do not like 
wonderland. I'm certainly one of the guy in europe that made the  
largest number of demoes of Squeak including Wonderland. I'm promoting 
the use of squeak in school, teachers...

Now I have a simple question: "who is we?"

You are talking about not breaking the code: first fixing wonderland 
would take 2 min if the code would be accessible.
Then if nobody sent an email to andreas saying that he is willing to 
help packaging Balloon3D then all these wonderful
discourse do not worth anything (just wind).

So this is ok to set define a milestone for an hypothetical version but 
again who should vote:
I vote for a multimedia distributed embedded secure flash like with pdf 
interface system....so what?
I will only consider the point of view of people doing stuff and I only 
want to set my agenda because this is
enough for me and I know what is it to be commited and responsible 
aboiut something.
I suggest everybody on this list to read the Scrum methodology and in 
particular the fun story about the chicken and the pig. In scrum only 
doers are actually the right to talk. This is a bit extreme to me but 
it makes a lot of sense.

And this is not that I want to give lessons because lot of people have 
the right to have fun with squeak and nothing
is black and white and newbie feedback is great and people trying 
packages and also people creating packages are **extremely** important 
but they do not have the right to tell me what I should do or not.

Now I stop and work

Stef

> I think we should add more attention to the media stuff of Squeak, as
> Mark has pointed out that we are overlooking thus for.
>
> Before getting into that, though, let me wholeheartedly with Trygve's
> comments.  No one should expect everyone to leap into their vision, 
> most
> especially people who are used to the way things are.  You either have
> to invest the time to convince them your changes are good, or you have
> to slave away in a monestary for years and then produce something that
> is so overwhelmingly better that a large part of the other guys will
> jump ship over to yours.  Squeak is already in the monestary compared 
> to
> many other computing systems, so I hope there is a way we can all
> continue together.  I don't really see a problem with that happening, 
> so
> long as everyone understands that everyone else is not going to
> immediately agree with them.
>
> (This also suggests that, we might want to develop some sort of voting
> system before too long.  I suggest looking at the organization of the
> Debian project, as I usually do.  :))
>
> Also, let me suggest a probable concensus item: everything on 
> Stephane's
> list is something every Squeak user would be like to be easily 
> available
> at some point in the future of Squeak.  It might not be in the base
> image, but it should at least be easily installable.  What we are 
> really
> discussion here is what order to do things in.
>
>
> Here's the twist I want to propose: for Squeak to be Squeak (see the
> What is Squeak thread), we really need for the computer media goodies 
> to
> function.  That is Squeak's raison d'etre, and it's the primary reason
> we should expect people to come and check out Squeak.  Further, the
> secondary goal of being a good computer playground, will be well served
> almost no matter what we do.  People trying to evolve the system, will
> almost certainly want to tear apart whatever the initial image is,
> anyway.  Further, people trying to evolve the system, will likely have
> the chops to be able to load a few extra packages.  This is not true of
> people who want to try the best personal computer-media system in the
> world.  A graphics art major just is not going to spend the time to 
> mess
> around on SqueakMap loading extra packages and toggling preferences
> before they can do anything.
>
> Thus, I propose that very soon--3.9 or 3.10--we make a concerted effort
> to get a really stable Squeak together for media users.  At the least,
> all the play with me's should work, all the tutorials should work,
> everything in the nu blue book that is feasible should work, and
> everything in alan's talks should work and be accessible.  This is a
> very doable goal, and it's a specific list of requirements.  Further, 
> if
> we do it right, then we can also develop a regression test suite to 
> make
> sure that this stuff keeps working in future versions.  Even if not, 
> the
> 4.0 that Mark suggests would leave behind a 3.9 where all the media
> stuff actually works; if we created a 4.0 right now, that is apparently
> not the case.
>
> Finally, let me agree that some of this stuff will indeed become
> experimental hacks of the past.  This is not the case yet for EToys, 
> the
> MIDI synthesis stuff, and Wonderland.  Keeping these things working is
> not sticking ourselves into the past; it's keeping true to Squeak's 
> core
> offering to its largest userbase.  Let's wait until *after* Croquet is
> available, before we obsolete Wonderland and EToys.
>
> (On the other hand, feel entirely free to dump MVC.  Why is dumping it
> not on anyone's list?  If you want a lean Squeak, you should go back to
> one of the 2.x's anyway.  It's one of the best ways imaginable to
> simplify Squeak.)
>
> What do people think?  Would anyone actually work on fixing etoy and
> wonderland, etc., bugs, if that were the primary goal for Squeak 3.9 or
> 3.10?  Would anyone be interested in development test suites for these
> kinds of things?  It sounds like an interesting research problem by
> itself: how do you test that wonderland is still usable as it is
> described in the nublue book?  It is likely to be partially manual, but
> a lot could be automated as well.
>
>
> Lex
>
>
>
> PS -- and really, let's stop cleaning things if it breaks code.
> Cleaning by itself just isn't that valuable.  If you really think it's
> worth the price of broken code, then pay the price yourself and fix the
> stuff up.  At the least, check that everything in a full image still
> works.  And ideally, try making a super-full image by loading 
> everything
> from SqueakMap, and seeing if *that* image still works.  Generally,
> let's be very wary of creating more work for each other.
>
> PPS -- there is absolutely nothing stopping us from having *three*
> images moving forward, if we want: basic, full, and bernish.  (or 
> maybe,
> basic/media/systems).  Let's please not make basic more of a
> battleground than it needs to be.
>