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