Re: Pharo 1.2 and test failures
Posted by
Mariano Martinez Peck on
Mar 06, 2011; 8:24pm
URL: https://forum.world.st/Pharo-1-2-and-test-failures-tp3337119p3338014.html
I think there is no magic here. If you want daily build images, then you have 2 options:
1) Always use ALL last version of everything
2) Use last metacello version. Someone needs to update each configuration.
If you want 2), then the PEOPLE needs to update configuration. There is no magic. Don't expect to always use the last code. If you want to use 1), perfect. But don't expect that the image is always working perfect: most repositories are public, so people can commit crap, and even more, some repositories are shared with squeak so someone can commit something that doesn't work with Pharo.
We have to choose.
To implement 2) then the Hudson script should be updated so that it loads the bleedingEdge: symbolic version of ConfigurationOfPharo.
cheers
mariano
On Sun, Mar 6, 2011 at 8:48 PM, Dale Henrichs
<[hidden email]> wrote:
On Mar 6, 2011, at 11:29 AM, Stéphane Ducasse wrote:
well, I provided a fix already. And it seems that 3 mails to the list and the mentioning withing this mail does not make it visible. It needs an integration step or just to load the newest ImageForDevelopers
How to tell?
I think the ConfigurationOfPharo needs to be updated...
Probably. Do you know what was the problem? Because I can have a look but I need to know what went wrong.
I am all in all not happy with the process we have... we should fix it.
I would not be that negative. I think that we are building an infrastructure and learning how to use it.
Generating one single image is easy. Generating an infrastructure to be able to manage multiple images over different
setup in another story. I think that metacello is getting there and also knowledge. This is why I spent time writing and fixing the
metacello chapter. Now there is more than 30 pages and with the latest important features like symbolic configuration.
I spent 2 hours to integrate one single changes for shout last week-end, so I know the pain now I think that the situation will
get better. Then else I would like to know your solution and roadmap?
For me this is clear: metacello and distributions are the way. I like that alex and dale are pushing tools on top of Metacello
because we have first class spec and dependencies and we can use them to get to a much better stage and we will get there.
Stef
The integration process for Pharo dev should parallel the process for creating PharoCore ... I'm not familiar with the PharoCore integration process , but after a bug is submitted for fixing, someone changes a script or a config to get the change included in the next PharoCore build ... the same thing needs to happen for Pharo Dev ... the Pharo dev configuration has to be edited to include the proposed fixes ...
The developer submitting the change _could_ update the configuration or the "owner" of the configuration could update the config or ....
I can imagine more possibilities ... right now it probably makes sense for an owner to make the changes ... that way if there are configuration issues the owner is responsible for fixing the issues the owner could also filter the changes, much the same way that the bugfixes for PharoCore are filtered ... once the manual process settles down we can look at improving the process and tool support incrementally...
Dale