[squeak-dev] Re: [Pharo-project] cant squeak map

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

>
>
> regards, Göran
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

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

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

> Hi!
>
> (being the creator of SM I can't resist this thread on Pharo-list...)
>
> Yes, I am cross-posting, so sue me.
>
> Stéphane Ducasse wrote:
>> Yes yes  yes but we do not use SM since years.
>> I cannot load one single package without breaking my image.
>> If you read the comments of a package you should not load it because  
>> most
>> of the time people entered that the code may work.
>> Then the version identification is often obsolete.
>
> The above is not really a problem with SM "as a tool" but with the
> contents of SM. 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.
> Understandable but still a pity we couldn't create some harmony there.
>
> PU was a clear "fork" of SM (not the codebase but the use case) adding
> dependencies. I still think it was sad that people couldn't instead help
> out in SM making it better.
>
>> So you may be able to load SM in pharo but we will not use it as a
>> way  to manage code.
>
> Ehm... SM was never meant to "manage code". It is not an SCM.
>
>> Sorry guys. clean SM first if you want it to be a credible alternative.
>
> This last line is... odd. What do you mean with "guys"? 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*. If SM3 also covers the functionality that PU has
> (dependencies etc) then perhaps we could migrate over to it from PU. Or
> again, we could make SM3 be able to "auto mirror" PUs, but that would be
> less optimal I think.
>
> Yes, I am picking up Deltastreams, have fixed lots of broken tests over
> the last few days and have read up on Matthew's code. I think DS is a
> really promising technology that can open up new nice tools, and still
> not compete head on with MC/MC2. Instead it should hopefully replace
> changesets and form a nice complement to MC/MC2.
>
> Finally, I have always felt that SM should work in as many Squeak images
> as possible - and Pharo is one of them of course. I don't care if Pharo
> decides to not have SM as a "first class" citizen - as long as it can be
> loaded into Pharo, and I will try to help out with ensuring that it can
> - hopefully that is an effort that Pharo developers appreciate. (?)
>
> regards, Göran
>
>
>