This thread was mentioned recently (on the SqF list, I think), so I decided to revisit it.
I definitely agree with Martin's original point that there needs to be a "core" or "base" set of packages, roughly equivalent to what's in the base image now. These packages would make up each "release" of Squeak, and would have some sort of guarantee that they would be maintained, and would be somehow tested with each release. (Well, tested at least as well as the image is tested now. ;-) )
A Debian-like pipeline of releases sounds like a good idea, too. Although I think we should not move to a scheme like that right away... let's go through at least a couple of releases first and make sure we have our current process under control, before we consider that.
One question I have for the Debian users out there, related to the recent release timeline discussions... how often does a new Debian release come out? (i.e. roughly how often does the Debian "testing" release move to "final"?)
- What are the rules for licenses? Should core packages be available
under Squeak-L? (my view)
For the short term, I agree that we should stick with Squeak-L for core packages. For the long term, I wonder if we might end up wanting to allow other licenses, but they would have to be "Squeak-approved" licenses, in the same way that Debian has Debian-approved licenses. Or maybe not, but it's a thought. :-)
- 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'd say probably yes, eventually.
- Doug Way
goran.hultgren@bluefish.se wrote:
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