Hi!

Stéphane Ducasse wrote:
>> Hi!
>>
>> (being the creator of SM I can't resist this thread on Pharo-list...)
>>
>> Yes, I am cross-posting, so sue me.
> 
> No we are not like that :)

Goodie. :)

>> The above is not really a problem with SM "as a tool" but with the
>> contents of SM.
> 
> Indeed.
> 
>> And as I predicted a few years back, SS (Squeaksource)
>> and PU (package universes) are indeed competing with SM and would  
>> (as it
>> did) cause us to get a fragmentation. I am not blaiming anyone, but  
>> I do
>> see that as the primary cause of "data rot".
>>
>> Since a lot of projects use SCM hosting as available on SS they don't
>> bother taking the extra step in keeping entries at SM fresh.
> 
> Come on. The publish was broken for years.

Yes, broken in SS, not in SM AFAIK. Which indeed made it hard to keep 
entries in SM fresh, I have never looked into it because I haven't had 
that itch myself.

[SNIP]
>> And why do you think "cleaning it" would solve something? I am not  
>> saying that cleaning
>> is not needed - just saying that cleaning is not solving the real
>> problem. We can't seriously tell people to maintain their packages  
>> in 3
>> different places (SS, PU, SM) IMHO.
>>
>> I am interested in creating a new SM3 that can replace both PU and SM
>> and that plays very well with SS installations (there are more than  
>> one
>> even though squeaksource.com is the most important one) and can use
>> Deltastreams. By "replace" I mean that SM3 of course should simply
>> replace current SM but also that it could possibly "auto mirror"
>> packages from SS installations making them available on SM3 *without  
>> any
>> extra effort at all*.
> 
> I think that the key point is that somebody is responsible for  
> publishing package in
> a public ready to use Universe/Version

I think it boils down to three different aspects/use cases:

- Making versions/projects available in a single nice catalog (SM, SS)
- Making controlled releases for a set of loosely defined environments (SM)
- Making controlled releases for a specific environment (PU)

The first is in its simplest form just access to an MC repo. Or just 
access to code in some other form on SM - load it at your own peril.

The second is slightly more defined, since SM doesn't automatically 
expose "all versions" but only those that you specifically put there, in 
combination with categorization for Squeak version etc - it is not as 
"wild" as SS is.

The third is hard core controlled - a specific version ONLY for a 
specific image. Including dependencies etc.

regards, Göran