Package grouping (was SqueakMap vs Debian)

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Tue Feb 18 12:13:27 UTC 2003


Hi all!

Martin Wirblat <mw.projanynet at SoftHome.net> wrote:
> Hi Göran and all,
> 
> after rethinking the SqeakMap - Debian analogy, I got more than ever the 
> impression that it is important to have a pipeline like Debian with 'next Core' 
> to concentrate future efforts on one working whole. 

Ok.
 
> However the most important thing is, to assure that something what is released, 
> is working like an image today. To make more clear what 'core' is, I added to 
> its name 'release' and the version number. So my suggestion for the packaging 
> categories would be: 
> 
> 'final core release 3.2'  <- historic 
> 'actual core release 3.4' <- must work more or less, will become 'final'

Sortof like Debian testing I guess.

> 'next core release 3.5'   <- experimental and in flux, will replace 'actual'

And Debian unstable.

> 'extra packages'          <- every package else

Ok. Those packages have their own lifecycle then. Fair.
 
> The 'core release' is what is now the image, and in future it will be the 
> minimal image + core packages. A 'core release' is characterized by: 
> 
> - core packages can only depend on packages in their core release 
> - a guide or mechanism for possible combinations of core packages
>   e.g. onion-skins

We have "load scripts" and the upcoming package configurations that will
handle these things.

> - the test of all allowed combinations working together as a customized image

Yes, this is an interesting side problem - I am visualizing a server
that starts a minimal kernel, loads packages and run their tests. In a
whole lot of combinations, over and over and "publishing" those results
(typically like a Resource on SqueakMap, but that is not important
here).

Sortof like an package integration test robot. It would/could also
verify package configurations that people will be able to publish in
SM1.1.

> - something like a 'guaranty' that every package is maintained

Spell check: guarantee.
But I agree.

> - this guaranty has to be made by the community, not a single person

Right. But I still want a maintainer for each package.

> - works like a pipeline, with 'actual' -> 'final' and 'next' -> 'actual'
> - is meant to grow over time ( like Debian )
> 
> To keep things simple, I think we can merge 'extra packages', 'normal packages' 
> and 'core replacements' into 'extra packages': 
> 
> - packages can depend on everything, even historic and next releases
> - hopefully maintained by a single person or team, but no guaranty
> - this is always the place for something new like Traits
> - packages with such big impacts can make it only to 'next core release'
> - packages which are more peripheral may go to 'actual core release' directly

Sounds fair. The simpler the better.

> The difference between 'core release' vs 'extra' is not about kernel vs tools 
> or applications. Even applications can stay perfectly well in the 'core 
> release' ( see todays image and Debian ).

Right. And we have/will have "load scripts" and other means of
describing groups of packages etc.

> The difference is only this:  
> - only 'core release' is tested and guaranteed to be working now and in future
> - 'core release' is the evolution path for Squeak
> - 'extra' is the space of virtual possibilities
> - 'core release' is what seems valuable for all AND on which many need to 
>   depend on 
> 
> This dependance is meant to be not only programmatic. Squeak the visual, 
> collaborative framework depends on tools and applications too. 

Of course.
 
> One last thought about guaranty. I think a guaranty can't be given by a single 
> person. At least no one can rely on such a guaranty. If many guaranties like 
> this will be promised, some will be broken. That's why I would suggest to make 
> the 'core release' so that the community is able to take the full 
> responsibility for it.

Well, I agree - but I think we should have one or a few persons
maintaining each and every package regardless of the grouping above. But
sure, the community is betting a lot on the core packages so the
maintainer needs to be aware of this and if the maintainer wants to step
down - the community needs to step in and find someone else to maintain
it.

A question to us all:
- What are the rules for licenses? Should core packages be available
under Squeak-L? (my view)
- Should we have other rules? For example, should core packages be
forced to include unit tests? (my view, and we need to create tests for
packages that don't have them)


I think I like the scheme above. I need to hear more discussion of
course but it seems smooth. And SM should be able to cope fine using
package releases and categories.

> regards,
> Martin

regards, Göran



More information about the Squeak-dev mailing list