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 at bluefish.se wrote:
> 
> 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