The general release plan sounds great: clean up 3.8/3.9, then for 4.0
focus on partitioning.  (please.  PLEASE.  stop speaking in codewords
like "TFNR".  It causes people who might want to help, to click "delete"
because they don't even know what the message is about.)

However, two important items were left off the list:

	1. Work out a way to release a set of packages this time, and not just
an image.  If this is nothing else than a zip file with a bunch of
packages in a subdirectory, that would be fine.  We really need this to
give people  a stable basis for working in Squeak -- especially as more
and more stuff ends up in packages.

	2. Get a bug tracker going so that we can see what specific packages
have open release-critical bugs in them.  Otherwise, the work in #1 is
much less useful, because we have no way to tell how stable different
packages are.

Additionally, the UI abstraction task is fine but seems relatively
unimportant compared to these other items.  How muh code, really, is
going to find it useful to target 5 different UI's?  Some, to be sure...
 but the above two items are easy and important.  Without them, dividing
the image into packages can actually *hurt* people who want to use
Squeak (instead of developing it further).

For motivation, just picture someone who wants to develop software in
Squeak, but not take part in developing Squeak itself.  They decide they
want to try Monticello... boom.  Why boom, when it's available on
SqueakMap?  Because they are using a 3.5 image, because 3.6 and 3.7
broke their networking code, and because 3.8 and 3.9 seem too unstable,
and because people keep posting new packages to 3.5 without thoroughly
testing them.  It should be normal that people can actually use stable
releases to develop in, but doing so is a hassle if both (a) everything
is in packages and (b) there are no stable releases of packages.


Lex