I think it's possible to produce a diff of all ConfigurationOfXXX between a built and the previous one, downloadable from Hudson. Then when something change we can know which ConfigurationOfXXX has been updated and then detect the cause of a new failing test.
Laurent On Mon, Mar 7, 2011 at 12:17 AM, Norbert Hartl <[email protected]> wrote: > > On 06.03.2011, at 21:24, Mariano Martinez Peck wrote: > > 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. > > 3) copy a fixed set of mczs to a repository and use the baseline > > I thought that all mczs are copied to a let's say pharo 1.2 repository. In > this case you don't need metacello versions because it loads the newest > version which is always true. Well, it is always true if integrating fixes > means that the changed package is put into that specific repository. But it > doesn't seem to be like that so I have to read it again :) If the packages > are taken from their own repositories than I don't see another way than to > nail the version in the metacello config and update as soon as a package is > updated. A tool like the browser will ease this step. > > Norbert > > 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 <[email protected]> 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 >> >> I agree with Stef ... the solution is going to involve both tools and >> process and at the moment Metacello tools are almost non-existent (Alex and >> I are trying to change that ... excellent effort Alex!) and we are still >> learning the process ... >> >> 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 >> >> >> > >
