Göran,

Just a clarification ... my work on github/metacello should work on all three platforms: squeak, pharo and gemstone. 

The filetree repository which is used to store Monticello packages in git allows one to share source code amongst 7 different smalltalk dialects[1] and work is ongoing to have it functional on VA as well.

Benoit,

It isn't necessary have a commit storm on a single package ... Metacello associates specific mcz files with a Metacello version which are immutable (by convention), so you won't be affected if someone commits a newer mcz package ... 

Also, there are several different approaches for making projects portable across multiple platforms:

  - partition project into multiple packages isolating platform
    dependent code into platform specific packages (i.e, Grease-Core, 
    Grease-Pharo-Core, Grease-GemStone-Core)
  - create platform-specific branches of a single package (i.e.,
    Grease-Core.common, Grease-Core.pharo, Grease-Core.gemstone, 
    Grease-Core.squeak)
  - using git, create platform-specific branches

Metacello then associates the set of mcz files that work together in a single version (with different set of files for each platform). Common code is typically in a shared package ....

Dale


[1] https://github.com/CampSmalltalk/Cypress/blob/master/README.md

----- Original Message -----
| From: "Göran Krampe" <goran at krampe.se>
| To: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
| Cc: juan at jvuletich.org, "Ron Teitelbaum" <ron at usmedrec.com>
| Sent: Friday, December 21, 2012 4:01:00 PM
| Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo..
| 
| Hey!
| 
| On 12/21/2012 10:58 PM, Ron Teitelbaum wrote:
| > I’m happy with the fragmentation.  I wasn’t at the start of this
| > conversation but I think I’m starting to appreciate it.  I agree
| > that
| > the goals for each are a bit different and having separated
| > achieving
| > those goals is easier.  We are building some new stuff and it seems
| > that
| > selecting the right fork for the right job “may” not have been
| > possible
| > without the split.  There are a number of new developments coming,
| > (in
| > the VM, Spoon, Seaside, Cuis, EToys, …) and it’s possible that one
| > big
| > monolithic Squeak may have made it more difficult for all.  It
| > seems
| > that we are closer to having split up the components then we had
| > thought.
| >
| > I know we cannot make everyone happy.  It seems that the starting
| > point
| > which seems to me to be COG, is the common link that binds
| > everything
| > else.  Let me know if you think that is wrong.  If that is true
| > then
| > building Squeak, or Pharo, or Cuis from a single point seems like
| > something that might help bring the communities back together.
| >  Will
| > Github or SmalltalkHub help to accomplish this?  If this were a
| > goal
| > would either do more than the other?
| 
| Github is nice and I applaud if we have the ability to use it.
| SmalltalkHub is on the other hand "our own puppy" and fully MC
| focused,
| so the advantages would typically be:
| 
| - Only Smalltalk stuff, no line noise of other things.
| - MC is still a much smoother ride than mirroring to files and using
| external tools like git.
| - Since we control SmalltalkHub we can tailor it for "Smalltalker
| needs"
| 
| Disadvantages are obvious of course, but I tend to think SmalltalkHub
| has a good spot.
| 
| > I agree with the goal, we want to be able to load a package and
| > have it
| > work and it would be nice if the dependencies were limited/managed
| > such
| > so that it will load in any fork.  Not all packages will load in
| > every
| > fork so knowing which will work beforehand is preferable.  VW is
| > different since nobody expects that with some work it will run on
| > Oinq,
| > I mean Cog (my name for the vm didn’t stick).
| >
| > It seems to me that it doesn’t really matter.  There seems to be
| > some
| > movement behind Metacello and SmalltalkHub.  Sometimes movement is
| > preferable to good ideas.  If Metacello works for Squeak and will
| > work
| > with SmalltalkHub should we not include it in Squeak to give it a
| > boost?  If Squeak goes with GitHub will Pharo follow?
| 
| - Metacello indeed works for Squeak. And has done so for quite some
| time.
| 
| - Metacello already works with SmalltalkHub. This is because
| Metacello
| is simply a layer on top of Monticello so SmalltalkHub (or any other
| MC
| repository) needs to know about Metacello. That is a very good thing.
| 
| - I think it would be good if Squeak endorsed/considered Metacello a
| primary tool. And nothing stops us from adding better support in
| SqueakMap to deal with it.
| 
| - And finally, no. Pharo does what Pharo wants :). But Pharo is
| closer
| to working with github than Squeak is, given several git and github
| related efforts in the Pharo community (Dale himself too). :)
| 
| When it comes to the Pharo vs Squeak "debate" it is IMHO quite
| simple.
| Pharo has their own agenda and the core people are doing a lot of
| good
| work there. As a Smalltalker, Squeaker and Pharooner I applaud it and
| love it.
| 
| BUT... just because the Pharo project is independent doesn't mean
| there
| aren't lots of us straddling both (or more) camps and want to do
| cross
| platform tooling and libraries etc. Dale Henrichs is one such shining
| example, and he of course also covers Gemstone.
| 
| At the same time sometimes time and effort is colliding. Take for
| example my Riak binding and coding on Oak (a... kind of OODB) - I
| picked
| Pharo explicitly for the Riak binding and Oak too - simply because
| there
| was extra effort trying to be cross platform. That is something we
| simply need to live with.
| 
| 
| > Nobody likes change but if we would all benefit from adopting some
| > similar tools should we not consider doing that for the benefit of
| > the
| > entire Smalltalk community.
| 
| I would think so.
| 
| regards, Göran
| 
|