a summary of the "blame" thread

The recent "blame" thread seems to have touched on a sore point for some folks and the discussion has devolved into a melee of clashing  (s)words -- which in general is pretty counter-productive.

I read through each of the messages in the thread and tried to pick out the concrete questions/issues that were brought up. I ignored the many meta arguments that went on and I may have missed some subthreads of importance, but I was surprised at the number of issues that were raised in the course of two days:):

the lost author/timestamps  subthread
the exchange code between dialects subthread
the what is collaboration subthread
the git is not smalltalk subthread
the central server vs distributed server subthread
the git support is important to new business subthread
the iceberg has bugs, therefore it is wrong to use git subthread
the Monticello is perfect so it isn't necessary to use git subthread
the it works for me there it will work for everyone subthread
the multi-platform support subthread
the we at y think git is cool, but disagree with the approach taken by z subthread

Each of these points/issues/arguments for the most part is important, some not so important and some already addressed, but amazingly the vast majority of the topic never got a reply as some of these threads were buried in a message that also contained meta arguments.

In re-reading the list it is clear to me that my personal bias crept into the short summary, but frankly when I reread those messages I wasn't able to summarize the actual point, because it was not necessarily clear what the real point was --- not enough detail ---  I included it with my funky interpretation because it is probably worth discussing at some level, but the discussion deserves more substance.

I seems to me that each of the dialects in play: Cuis, Pharo, Squeak, and GemStone has consistent answers to each of the subthreads, but perhaps it is the cross-platform nature of of the issues that is at the core of the arguments ...

Pharo has taken the bull by the horns and committed to using git/github for the Pharo kernel source code and thereby committed to making it easy to use git (and presumably other disk-based SCMs ... eventually) from within the Pharo7.0 image ... the decision has been made and the conversion pains are being felt (which is not unexpected).

Clearly this move by Pharo does have an (eventual?/varying) impact on the other Smalltalk dialects.

For GemStone we are moving pretty much in the same direction as Pharo is moving and for many of the same reasons ... I have been grumpy about the unilateral move to Tonel, but

We are expecting to introduce git/package/Metacello support in the base in the next release of GemStone (just a simple matter or resources:).

We are using Tonel and git in our internal product development process in a limited way.

Besides the obvious reasons, Metacello support is there so that our customers who are not using GsDevKit can have the option of loading/contributing to open source Smalltalk projects hosted on github. We do not plan to support .mcz files in the kernel.

We will most likely base our kernel  git tools support on bash command line git (a feature that has been in tODE for about 5 years). Our server product is not supported on Windows, so we can get away with that.. Windows clients are supported, but not Windows servers.

With regards to central vs. distributed server, we lean towards distributed servers. We have a number of customers whose production systems are behind firewalls that make it very difficult if not impossible for the Smalltalk developers to access network-based Monticello web-sites let alone CVS-style centralized servers. So making it possible for those developers to use local git clones "transparently" is a seen as a real advantage ...

Finally our open source GsDevKit project has a Pharo compatibility layer, so being able to share source code with Pharo is a priority and Metacello is a key component in that support. Monticello .mcz files will continue supported in GsDevKit as long as the critical projects for customers continue to be hosted in  Monticello .mcz repositories ... eventually I expect .mcz support to become an optional component in GsDevKit, but I won't put a date on it since I do expect to support Monticello for some definition of forever:)

Dale