On 30/03/2018 23:56, Nicolas Cellier wrote:
Hi, Several problems are mixed here, let's try and decouple:
- there are ongoing development in the core of VM that may introduce
some instability
- there are ongoing development in some plugins also
- there are infrastructure problems preventing to produce artifacts
whatever the intrinsic stability of the VM
For 1) development happens in VMMaker, and we have to be relying on experts. Today that is Eliot and Clement. We all want 64bits VM, improved GC, improved become:, write barrier, ephemerons, threaded FFI calls and adaptive optimization. Pharo is relying on these progress, they are vital. IMO, we are reaching a good level of confidence, and I hope to see some VMMaker version blessed as stable pretty soon.
Instead of whining, the best we can do for reaching this state is help them by providing accurate bug reports and even better reproducible cases. Thanks to all who are working in this direction.
For 2) we had a few problems, but again this is for improving important features (SSL...) Much of the development happens in feature branches already. But since we are targetting so many platforms, and don't have automated tests that scale yet, we still need beta testers. We can discuss about the introduction of such beta features wrt release cycles, that will be a good thing. Ideally we should tend toward continuous integration and have very short cycles, but we're not yet there.
For 3) we had a lot of problems, like staled links, invalid credentials, evolution of the version of tools at automated build site, etc...
If we don't build the artifacts, then we can't even have a chance to test the stability of 1) and 2) We have to understand that 3) is absolutely vital.
May I remind that for a very long period last year, the build were broken due to lack of work at Pharo side. Fortunately, this has changed in 2018. Fabio has been working REALLY hard to improve 3), and without the help of Esteban,I don't think he could have reached the holy green build status. We will never thank them enough for that. This also shows that cooperation may pay.
But this is still very fragile. If we want to make progress, we should ask why it is so. We could analyze the regressions, and decide if the complexity is sustainable, or eventually drop some drag. We are chasing many hares by building the VM for Newspeak/Pharo/Squeak i386/x86_64/ARM Spur/Stack/V3 Sista/lowcode linux/Macosx/Windows ... If it happens that a fix vital for Pharo/Squeak does break Newspeak tests, then it slows down the progress... Maybe we would want to decouple a bit more the problems there too (they may come from some image side weakness).
Last two years I've also observed some work exclusively done in the Pharo fork of the opensmalltalk VM. This was counter productive. Work must be produced upstream, or it's wasted. I once thought that the Pharo fork could be the place for the pharo team to manage official stable versions. But I agree that this is too much duplicated work and would be very happy to see the work happen upstream too.
If you have constructive ideas that will help decoupling all these problems, we are all ear.
PS: i did not post this answer for avoiding sterile discussion, but since Phil asked...
Hi Nicolas,
Thanks for this explanation. It's helpful for people like me who work only with the image side of Pharo and only begin to read the work done on the VM side. It's not always obvious what are really the problems when we do not know the exact situation and can sometime leads to misunderstanding.
If the community have some ideas on how to improve the current infrastructure but does not have the time to do it currently, maybe it could be good to list them on the github issue tracker with an "Infrastructure" tag? Like that if someone complains and is ready to help a little you can just send it the link of the issues tagged "Infrastructure".