[Vm-dev] Need an Alien-Core-eem.102 update

[Torsten Bergmann]

Hi Eliot,

>there's a simpler solution.  We simply delete Alien-Core-TorstenBergmann.101

Yes - no problem with that and thanks for taking care. But a copy might exist still in local Monticello caches
on user side.

So an Alien-Core-eem.102 as Dave suggested would nonetheless be the safest addition to compensate
the Alien-Core-eem.101.mcz (where 101 version was used unfortunately a second time).

>I'll do that by Monday if no one objects. I'm sure Torsten meant no harm and was
>unaware of the issue.

Yes - for the timestamp I did not notice directly (or even forgot because I guess I just had a newer Pharo
image on the machine which was already switched git but still includes MCZ tools).

But if you really require the timestamps explicitly on each method for the VMMaker / Alien packages
then it means one is only allowed to use Squeak or old Pharo versions to contribute / commit and
VM development will never move away from MCZs in all our lifetime.

The Pharo tools do not have the timestamp in MCZs anymore due to the switch to GIT. Because having the timestamp in the file
format directly would always mean a change/conflict in the diffs of git anytime - even if there is no real code change
on the method or class itself.

We all know git is widely accepted in IT shops around the world, really a breeze to work with - now even with and in Smalltalk code.
With git one gets timestamps out of the box - but also a lot more like proper branching (which is nearly impossible
to handle in MCZs for the Monticello/Metacello approach). Also GIT can version Smalltalk and non-Smalltalk code
at the same time and using the same way.

In fact one rarely finds a project which is Smalltalk code only - often you have other assets or code in other languages too.
And VMMaker is a good example for that.

I personally therefore like git much much more than the old more limiting MCZ solutions. Seen from the outside I still fail to
understand why

  - on one side the VM code is maintained with git on GitHub
  - on the other side the core Smalltalk parts like VMMaker are still versioned as MCZ and hosted on old services like
    SqueakSource / source.squeak.org

Even Squeak might hopefully move forward and use git in the future. Then VMMaker will face the similar issue with the
timestamps. If I understood sources like

   https://hpi.de/fileadmin/user_upload/hpi/dokumente/publikationen/technische_berichte/tbhpi121.pdf

correctly then one can already use Git as a backend VCS from Squeak too.

>Torsten is a very nice guy.

Thanks for the compliment - but like any other human I have a dark side too :)

>But the issue of no time stamps intr4oduceing lots of noise into Monticello repositories
>is an annoying g piece of passive aggressive B.S. from the Pharo community which we should push back against.

What kind of noise exactly are you referring too?

No need for a conspiracy theory or blaming of the overall Pharo community - loosing the timestamp is related to the
git switch as explained.

I know there are sometimes personal differences among members of the various communities - and there is potential for
conflicts depending on personality and if the (code) area of work is the same - and when the ideas for the solution(s) differ.

But basically in all the communities I assume the individuals are trying to move things and ideas forward. Sometimes
we all pull/push into similar direction - sometimes not because goals or ideas differ slightly or even heavily.
I assume (and hope) nobody does harmful things willingly just to bug other sides.

Anyhow - I hope 2020 will be a good year with good progress for ALL the communities.

Thx
T.