Wasn't clear where you intended to post this (you sent a copy to each 
list), so I'm answering where it fits me :-)

It's possible us Guides have somehow failed to make this clear, but this 
is absolutely, positively, a very critical kind of post. We don't know
everything that should change about Squeak. We don't know all the
packages. Maybe people think we don't want to hear this kind of thing,
in which case we've failed to get across our most important message,
IMO.

My opinions below... 

Andreas Raab <andreas.raab at gmx.de> wrote:
> [repost with different subject - hit the send button too fast]
> 
> Daniel,
> 
> > convince a Harvester it should be an ENHancement, not a SM entry.
> 
> Funny you should mention this (see my post at SqF list) as I was just
> wondering how exactly one does this. 
Speak up. Specifically, address these things -
- you explain why it improves something that everyone needs (even if
this was clear the author thinks so, a second opinion sure helps).
- You say the code is good enough (review, lint, test), or work to make
it so
- You help see a way to integrate it. If it's small, that's usually
pretty trivial. If it's big SUnit tests will help. If it affects lots of
stuff, it might take some thinking.

> There are a number of things where I
> think they should absolutely be put into kernel Squeak. Here are a few:
> 
> * Network rewrite 
>  
> http://map2.squeakfoundation.org/sm/package/030feb79-34a9-4822-9a6f-d7d2e83a
> 0cef
>   Why: No changes to fundamental network semantics but an awful lot of fixes
> in a variety of areas. The last five times I got bitten by network code in
> Squeak I asked Mike and each time he told me "oh, I got this fixed long ago
> - just get the network rewrite".
I tend to agree. I tested this extensively for mail, and was very happy
with how it worked for that. I was expecting Michael was going to
continue doing the rest of the protocols, or work out some division of
the territory with Craig and Flow, but I guess life intruded. Since it
seems (I read some of the code, but not all) like a good replacement of
the current code for the same functionality, it might be best to just
bring it in in 3.6a, and remove the remains of the previous socket
implementation in 3.7a. If anything is broken, what people care about
will be fixed. 

> * TrueType text style
>  
> http://map2.squeakfoundation.org/sm/package/ab8088ce-4b01-4a15-bbff-82241d16
> 205e
>   Why: If you have to ask this question you are not using Squeak for any
> media activity. 
You may find this curious, but actually, I don't. So I have to.

> If you do, then you don't have to ask. This is not a package
> - it's a basic requirement for anyone who does media stuff.
Ok, then let media stuff doers load the package. We'll eventually also
be removing movie playing, sound and all that happy crappy into packages
that will be very easy to load, all at once, for people that want media
stuff. However, if you want to say it makes Squeak prettier/nicer for
all audiences, I'd be glad to read some details/raves :-)

> * Multilingualization
>  
> http://map2.squeakfoundation.org/sm/package/8b53bfb4-481c-4d3c-bf31-1b1018fc
> 3d33
>   Why: Even if Yoshiki claims that it is still in flux my gut feeling is
> that this absolutely needs users! I bet that we have couple of people on
> this list who would want to use it (even if only for localizing eToys) and
> the limited context in which to use it here would be quite beneficial for
> further developments. I think we should have Yoshiki set up the "absolute
> minimal version" that he thinks is reliable enough to be put into the hands
> of real users and then give it a go.
First of all, I agree this eventually affects something that should be
in the base image, and probably care about this more than most, since my
primary language has zero support in current Squeak. And Yoshiki has
gone the extra mile and made it an SM package, so theoretically the
barrier to test it is zero. I don't understand why there's almost no
feedback, the null hypothesis is that nobody cares enough. In which
case, I tend to not want it in the image.

I'm not very certain about this, because it seems like it is maybe a
problem of PR (there not being a cool demo or something), rather than
lack of goodness/relevance, but I'm no sure bundling it into the image
is the right way to fix that. Hmm, even as I write this, I get the
feeling it might be wrong, though I'm not quite sure why.

> There are a couple of other packages where I think it would be really good
> if they were part of the kernel image but these three I feel mostly strongly
> about.
Let us know.

Daniel