Here's my second initial project proposal, mostly triggered by the meeting with Paul.
The first project must be a no-brainer, reasonably easy to implement, and a test of the (initial) environment. I propose CVS/Sourceforge, I know it's not optimal for St projects but it is there, it works, and we can use it to bootstrap up to a Squeak-specific SCM system.
Proposal:
Calling SqC's hand on SqF cooperation, I propose that we put the VM plus a very minimal core class library on SourceForge, and call that the official Squeak reference implementation.
Rationale:
As Paul indicated in his notes on our conversation, there are lots of parallels between Squeak and Linux - as Linux is tremendously succesful, we might just as well learn from it :-).
Both systems are an operating system, and both are applicable in a very broad range, both horizontally (from iPAQ to "SqueakNOS for System/390 ;-)") and vertically ("BusinessSqueak", "SchoolSqueak", ...). Like Linux, a worthwhile model could be to define a very basic core (kernel, libraries) and have third parties build distributions on top of that with added value. So a BusinessSqueak could be core+networking+Glorp+Swazoo (with a competing one core+networking+Comanche+SMS), a SchoolSqueak would have Morphic and eToys, etcetera. Keep in mind, that's the general direction I think it useful, the first step I propose here is just a very minimal first step. A side effect of this operation is that we force the issue of modularity.
Squeak-Core (as I propose to name this bit) would define the de-facto standard, which automatically opens up a clear, minimal target for competing and/or platform-optimized implementations. The first work, apart from maybe some refactoring, could be to write unit tests for this core so that alternative implementations could be validated.
The "Calling SqC's hand" terminology I used above is in response to Dan's message indicating SqC's support for the SqF effort ("great, Dan - prove it" ;-)). Handing over the responsibility for the core to the community and pledging to cooperate on this bit would make this support very concrete. As it would be a extremely minimal bit of Squeak, it is very likely to consist of very stable code so that the impact on SqC day-to-day operations is likely to be small. That helps us to focus on procedures around SqC/SqF cooperation, roles, responsibilities.
Goal:
Produce Squeak-Core v1.0 on SourceForge.
Steps:
- (in parallel with the other steps) setup a mailing list where we can discuss the scope of Squeak-Core (probably VMConstruction plus stripped-down versions of Kernel, ST80, Collections, System - the goal is to have stuff in Core that must be present everywhere, no matter what the size of the platform or the application).
- Setup a SourceForge project or adopt an existing one for this goal.
- Setup a self-contained CVS changeset with some extra bits of code so that e.g. the Help menu is extended with SourceForge CVS interactions ("update code from SourceForge", "commit code to SourceForge", "send patches to Squeak-Core project mailing list", etcetera).
- Take a code cut and stash it into SourceForge. Call it "1.0.0".
- Start a machinery like the linux kernel machinery: Squeak-Core 1.1.x is hacking, alpha, unstable, when there's a nice set of new features start stabilizing until a version can be called 1.2.0 which is the next "official" release, etcetera.