Ralph Johnson <johnson <at> cs.uiuc.edu> writes:

> 
> There should be a Collection package.  And Numbers and Exceptions.
> 
> source.squeakfoundation.org is supposed to be a host for MC repositories
> for core packages.  Some of them are more active than others, and a lot
> seem to be missing.
> 
> I think we can get repositories for other categories IF people
> volunteer to manage
> them.  But these repositories will work only if the people who
> volunteer actually do
> the work when it is needed.
> 
> ...
> 

Andreas is right.
Core classes are present in each and every fork.
Bug fix and enhancements (like speed) should be shared.
Collecting them is tedious (the release team knows).
There is currently a lot of duplicated work (fork oblige).

Technically:
-----------

Remember you might need atomic loading for such core classes
(they are used by Compiler, Monticello, ChangeSet etc...).
Is this solved?

I am also quite sure that every fork will extend these core classes.
Preliminary work is to identify these extensions and mark them as such...

Socially:
--------

Who is the authority to decide what goes in core and what is an extension?
How to handle deprecation across several images (see the #hex mess for example)?
Shouldn't there be a backward-compatibility extension created?

The underlying goal of current organization seems to build a not-so-minimal
high quality core image, one on which to rebuild next version forks.
What do fork maintainers think of such approach?
Shouldn't members of major forks participate to the debate of what goes in core?
Wouldn't this help integrating fixes/enhancements happening in forks?

Proposal:
--------

Why not a distributed authority approach?
For example, a change can be accepted once 3 out of 4 forks agreed on it.
Or maybe qualified majority (2 yes, 1 no or less).
Not responding in time is an abstention.
Without majority, the change remains a specific extension.
I know, decision process sounds heavier than current process...
But this should provide better rationale and overall improvement,
and decrease duplicated technical work.

Nicolas