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
|