[Vm-dev] Status of VM

[Nicolas Cellier]

Hi all,

I'm not mandated by opensmalltalk organization nor anyone but myself. But
as a member I want to give my feelings.

There have been some tension recently concerning the release cycle of the
VM.
That's understandable because it's been a long time since we did not
produce a stable version.

Since December there is an ongoing effort toward this goal.
Eliot is doing his best efforts to solve the remaining garbage collect
problems. Thanks to all good souls helping with bug reports and
reproducible cases. That's the way to go. As you can see, most of the
useful reports came from Pharo, and Eliot gave a great care to them. So
Eliot is helping Pharo, whatever his primary goals or presumed intentions.
He must be judged on its actions.
Let's cross fingers about stability of latest artifacts.

I ear a lot of griefs about the process in public and private mails. It's
far from perfect, We can improve. The whole VM is highly dependent on
Eliot, that's true, it's also a weakness. We are a small community and it
take years to clone an Eliot. That's another reason why we should maximize
his value and let him work on the core features. But anyone wanting to
involve in such adventure and become another VM expert is welcome. Eliot is
caring and very accessible. That's a chance for all of us.

But this means that we must help ourselves for the non core features. Eliot
cannot integrate all the pull requests. So if Pharo needs a specific
plugin, a new primitive or whatever, then it's the responsibility of Pharo
team to help its integration. Hopefully, there's always been some help,
tips and improvement change requests from other members so far. And
remember that we are not all tainted! But please, I don't want to ear that
changes take ages to be integrated when no one from the concerned team
pushes them! Let's be responsible citizens.

We also must take care of the infrastructure, and our first duty is to not
let the CI rot in red, otherwise there's no process possible at all.
I wanted to have a look at this status which is red again. It's not
catastrophic, it was caused by a gcc bug and affected the pharo.sista.spur
and pharo.cog.spur.lowcode brands. I'm very happy to see all the goodwill
with tips and encouragement I received in a single day from Holger,
Alistair, Ben, Subbu, Fabio, Tobias, with their help, that's solved. But
it's not finished. The next step is to solve the deploy step that just
failed for Pharo (
https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/361346561) and
also the bintray problems which I do not understand and concern everyone (
https://ci.appveyor.com/project/OpenSmalltalk/vm/build/1.0.1219/job/2j1bu778vg9a2rpw).
More help wanted...

I also ear the fear from Pharo team that all the brands and backward
compatibility versions that we support become burdens. Yes they can if we
let them rot. We all know that Pharo's strategy is to go forward and not
encumber with compatibility. We respect this choice, but it's not the sole,
Squeak for example has a whole different strategy which is also
respectable. But that does not mean that Squeak is a burden for Pharo. The
Pharo team is responsible for the Pharo brand. The Pharo brands must
compile and pass tests so that the corresponding CI jobs stay green. The
Squeak and Newspeak team should do the same. If one brand rots for too long
and prevents other flavors to make progress, like integrating fixes, then I
suggest that we simply disable the corresponding entries in the build
matrix after a warning and grace period, and let it disabled until one emit
a PR with a fix. We value cooperative attitude, so cross flavor help is
welcome, but not mandatory.

There's also a cost of maintaining large code base. Remember that we share
most of the core VM and many plugins. We can break compatibility mostly
when we make the API evolve: either by modifying the parameters and
behavior of existing primitives, or by changing the plugin API itself. This
does not happen often and it's not been a problem so far. The rules are
simple: rather than breaking compatibility, we simply create a new
primitive. Nothing prevents a team to create and manage its own plugins.
There will be a growing base, but each team will be responsible for its
own. Fortunately, there's not so much coupling, so it's sustainable. For
me, the main grief is that the VMMaker code base itself is larger than
necessary and this is a barrier to newcomers, but one thing at a time, it's
been accumulating for years and inherited by opensmalltalk-vm, not our
exclusive creation.

The next points of friction are the organization of the process, the use of
branches, the choice of repositories for plugins, the automated builds,
etc... There's nothing that prevents constructive discussions. But the
preamble is to cool down and not throw accusation of incompetence or other
sarcasms, it will only raise emotional burden and be counter productive.
Let's address the technical problems one by one in small steps and be very
pragmatic. We don't want to change for changing. We want to change for
increasing efficiency.

The next points of friction is the control and prioritization of new
features, and their rate of introduction in the release cycle. That's not
unsolvable, we have common goals, like ephemerons for example, but there
must be a good will for finding middle ground and agreement. Also, the
manpower or money one can put in balance shall necessarily be taken into
account. Indirect contribution counts, but contracts rules. At the end, the
work has to be done. I’m convinced that Pharo has more to win by
participating in open smalltalk-vm than it will ever being able to pay.
Directly or not, there are 16 team members contributing to open
smalltalk-vm, only 4 rather Pharo oriented, and a few more contributors, so
please consider the cost of a new schism.

Last, I felt a lot of frustration and emotional burden already present. I
can understand, I'm myself very emotional. But we are all adults. If we
can't address our hard feelings, then yes, maybe we should just start
another activity. Personally, I go in the garden planting lettuce, that's
refreshing. Focusing on technical solutions and own goals may help too.
Please, let's all behave like adults.

I have seen talented people help us to grow these last two years, there's a
lot to learn from each other, and I'm happy if we can build something
together, even happier if more efficiently. Let's not spoil it. I wish we
can invent our future again. Let's take our chance.

PS: I'm not running for opensmalltalk presidency ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180403/bd25dd63/attachment-0001.html>