Hi all

I copied the preceding mail entirely and add my comments in it.
Content-wise this could become the nucleus of a document which 
describes the release strategy. (needs to be structured though)


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
>

I would like to make sure I understand you:

With "pipeline" you mean something like?

version         time ->
3.5 core         aaaa bbbb gggggggg f
3.6 core                      aaaa bbbb gggggggg f
3.7 core                                   aaaa bbbb gggg f             
             

or

version         time ->
3.5 core         aaaa bbbb gggggggg f
3.6 core                aaaa bbbb gggggggg f
3.7 core                       aaaa bbbb gggggggg f                     
     

a = alpha, b = beta, g = gamma , f= final

 
> Ok. Those packages have their own lifecycle then. Fair.

Yes, I consider this very important as well. As the core gets smaller
the release cycles of it may of it may get longer. Packages may
have a similar release scheme, but independant of the core.
  
> > 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

For this there is probably a general agreement.

> 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

So the artifact which corresponds to a release in the traditional sense
would
be a core image + a load script. Applying the load script to the core
image
results in a larger image which could be put as a pre-built image on
down
load pages as well. So the user experience would not much differ from
today.
The only difference would be that there would be several flavours of
prebuilt-images which is already the case today although in an
unsystematic way.



Build-Server
> 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.

A good goal, but probably relatively difficult to achieve at the moment.

> > - 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.

Yes!
 
> > - 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.

I Agree

> > 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.

In a general sense yes.
But what does this mean specifically? I think an individual or a group
should be 
responsible for coordinating efforts, maintaining check lists and making
sure that
tests are performed. At least at the moment.
We could further work on elaborating a "stewardship model"
where different teams are stewards for "estates" in Squeak object land.
(e.g. Collection, Basic Dev. Tools, Font, Editors, Kernel, Morphic,
Networking, VM, 
Example Worlds, Internationalization)

 
> 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.

I would vote for replacement of the word "maintainer" by "steward",
because for
me this implies a more active role. 

 
> 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

regards
Hannes