[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. 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".
* 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. 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.
* 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.
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.
Cheers, - Andreas
On Mon, 2003-05-05 at 21:25, Andreas Raab wrote:
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.
My take on this: I don't think these (maybe with the exception of networking) should necessarily be in the kernel in the long run; but for the short term I think it is necessary to 'intern' these cleanups if only in order to make sure that whathever is split off later on as a package is good, separable, and 'canonical'. They are maybe not packages that should land in the 100k bootstrap image ;-), but I do think that the functionality is basic enough to warrant some special treatment in order to make sure that we're left with canonical copies of networking, font support, and internationalization - three areas that are present in the image but need work, and the packages indicated by Andreas provide (part of) that work.
The argument could be (and has been, IIRC) that people who are interested in this stuff can grab it from SM, but running these packages through the 'add to image, clean up, split off' loop has two important effects: - it 'blesses' the package as 'this is what we think should be the official XXX package'; - it pushes it out to a greater number of alpha testers than when left on SM. Also, SM is not there yet. The coming months will be a balance act of getting people used to SM and making sure they see important code irrespective of the functionality of SM. Just solving every problem by pointing to SM at this point in time seems counterproductive to me. SM should work because it is good, not because Guides/Harvesters tell the community to use it. That won't work.
squeakfoundation@lists.squeakfoundation.org