Status of VM

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 ;)