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
