> I will try to promote then the one of 15 march. We’ll see next week. > but then, this is part of my observation: We cannot know which VMs are > stable, and that’s because the *process* to make them stable is very “human > dependent”: We consider a version stable when it builds on CI and Eliot says > is stable. But since Eliot does not use Pharo (not a critic, a reality), > that may be not true for Pharo. And that’s actually what happens, Pharo > crashes.
Hi esteban What would be a way to fix the process and make your work easier? If you do not know what can be a release candidate then who can? We should really improve this situation. Stef > I tried to avoid a bit this problem with our fork and nightly builds that > runs the pharo tests (to knew about problems as early as possible). But to > be honest I didn’t have the time (and the will) to work on it recently, then > pharo fork is in practice stalled. I will revive that eventually… but just > when I find the time and the spirit to do it. > > > to one more up to date than 2017 08 27 (in fact more up-to-date than > opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, Fri Jan 19 > 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes can result > in image corruption in large images, and can occur (as it has here) at > start-up, causing one's work to be irretrievably lost. > > > Most, if not all, the VMs between 1 Jan and 15 Mar have bugs that are > triggered either by the automated test suite or the bootstrap process. > > > The blocks I can see at the moment are: > > - Multiple builds have failed with an internal compiler error on the > sista builds. > -- The earliest occurrence I could find was commit 1f0a7da, but it may > have been earlier. > - Even if the Mac builds show success in travis, they aren't making it > on to files.pharo.org. > > > latest VM copied into files.pharo.org is 16/03. > we need to see what’s happening there. > > -- I haven't ever worked with this code. > > Not directly related, but: > - Bintray hasn't been updated since 8 March 2018. > > > I think it could also be useful for files.pharo.org to have release > candidate links available, which would help people to focus testing on > a particular VM. They would need to be manually maintained, but I > think the benefits would be worthwhile. > > > all VMs are available to test. > just… not available *directly* to general users. > now… I could have a 70rc link in vm subdir. But since I cannot know which VM > is RC I find it pointless at this moment. > > cheers, > Esteban > > > > Cheers, > Alistair > >
