[Squeakfoundation]Initial project - Squeak core

[Cees de Groot]

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.
-- 
Cees de Groot               http://www.cdegroot.com     <cg@cdegroot.com>
GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B