> 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 :) >> > > 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. > 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. Indeed >> 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"? anybody. If somebody wants to have sm on pharo then they should clean the database. > 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 > 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. Ok for me > 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. I'm interested into that too. > 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. (?) Sure! Stef > > > regards, Göran > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
