Hi all!
Martin Wirblat mw.projanynet@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