Pharo 1.2 and test failures

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Pharo 1.2 and test failures

NorbertHartl
Today I had a look at the hudson server. For pharo 1.2 dev there was only one bug left. So I took a look and fixed it


Two hours later there was a new build in hudson and then there were three bugs (one of these is the fixed one which hasn't been integrated). How can this happen? 

Norbert
Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 and test failures

laurent laffont
If I download Pharo-1.2-AfterRunningTests.zip #168 and try only Tests.Release.ReleaseTest.testUndeclared fails on my machine.

And I'm still not able to reproduce results of Hudson. If I run all tests I have far more failures and errors ( http://forum.world.st/Re-1-2-one-click-OSX-and-Linux-more-failing-tests-tp3327005p3327005.html )

Laurent


On Sat, Mar 5, 2011 at 10:55 PM, Norbert Hartl <[hidden email]> wrote:
Today I had a look at the hudson server. For pharo 1.2 dev there was only one bug left. So I took a look and fixed it


Two hours later there was a new build in hudson and then there were three bugs (one of these is the fixed one which hasn't been integrated). How can this happen? 

Norbert

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 and test failures

laurent laffont
testUndeclared is failing because of  DEVImageWorkspaces class>>openGettingStartedWorkspace and #openExternalProjectWorkspace

(I can provide a fix later).

Laurent 


On Sun, Mar 6, 2011 at 8:32 AM, laurent laffont <[hidden email]> wrote:
If I download Pharo-1.2-AfterRunningTests.zip #168 and try only Tests.Release.ReleaseTest.testUndeclared fails on my machine.

And I'm still not able to reproduce results of Hudson. If I run all tests I have far more failures and errors ( http://forum.world.st/Re-1-2-one-click-OSX-and-Linux-more-failing-tests-tp3327005p3327005.html )

Laurent


On Sat, Mar 5, 2011 at 10:55 PM, Norbert Hartl <[hidden email]> wrote:
Today I had a look at the hudson server. For pharo 1.2 dev there was only one bug left. So I took a look and fixed it


Two hours later there was a new build in hudson and then there were three bugs (one of these is the fixed one which hasn't been integrated). How can this happen? 

Norbert


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 and test failures

Stéphane Ducasse
We should remove the tests only crashing on the server for now.


Stef

On Mar 6, 2011, at 8:45 AM, laurent laffont wrote:

> testUndeclared is failing because of  DEVImageWorkspaces class>>openGettingStartedWorkspace and #openExternalProjectWorkspace
>
> (I can provide a fix later).
>
> Laurent
>
>
> On Sun, Mar 6, 2011 at 8:32 AM, laurent laffont <[hidden email]> wrote:
> If I download Pharo-1.2-AfterRunningTests.zip #168 and try only Tests.Release.ReleaseTest.testUndeclared fails on my machine.
>
> And I'm still not able to reproduce results of Hudson. If I run all tests I have far more failures and errors ( http://forum.world.st/Re-1-2-one-click-OSX-and-Linux-more-failing-tests-tp3327005p3327005.html )
>
> Laurent
>
>
> On Sat, Mar 5, 2011 at 10:55 PM, Norbert Hartl <[hidden email]> wrote:
> Today I had a look at the hudson server. For pharo 1.2 dev there was only one bug left. So I took a look and fixed it
>
> http://code.google.com/p/pharo/issues/detail?id=3784
>
> Two hours later there was a new build in hudson and then there were three bugs (one of these is the fixed one which hasn't been integrated). How can this happen?
>
> Norbert
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 and test failures

Marcus Denker-4
In reply to this post by laurent laffont

On Mar 6, 2011, at 10:00 AM, Stéphane Ducasse wrote:

> We should remove the tests only crashing on the server for now.
>

It's not that simple... a test started failing just yesterday. So I think the problem is that we are not
loading a *fixed* set of versions, but a changed one. e.g. someone commits a new version of a project --> it's loaded in 1.2

We need to change that. Especially considering that we want to build 1.3, too.
(we never build a 1.3 Full image...).

And there is 1.1, too, where the loaded packages seem to change depending on the moon, or something...

All in all, maybe we should re-think if how we do the full image is sustainable?


        Marcus


--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 and test failures

NorbertHartl
In reply to this post by laurent laffont
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?

Norbert

On 06.03.2011, at 08:45, laurent laffont wrote:

testUndeclared is failing because of  DEVImageWorkspaces class>>openGettingStartedWorkspace and #openExternalProjectWorkspace

(I can provide a fix later).

Laurent 


On Sun, Mar 6, 2011 at 8:32 AM, laurent laffont <[hidden email]> wrote:
If I download Pharo-1.2-AfterRunningTests.zip #168 and try only Tests.Release.ReleaseTest.testUndeclared fails on my machine.

And I'm still not able to reproduce results of Hudson. If I run all tests I have far more failures and errors ( http://forum.world.st/Re-1-2-one-click-OSX-and-Linux-more-failing-tests-tp3327005p3327005.html )

Laurent


On Sat, Mar 5, 2011 at 10:55 PM, Norbert Hartl <[hidden email]> wrote:
Today I had a look at the hudson server. For pharo 1.2 dev there was only one bug left. So I took a look and fixed it


Two hours later there was a new build in hudson and then there were three bugs (one of these is the fixed one which hasn't been integrated). How can this happen? 

Norbert



Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 and test failures

Marcus Denker-4
In reply to this post by laurent laffont

On Mar 6, 2011, at 11:32 AM, Norbert Hartl 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...

I am all in all not happy with the process we have... we should fix it.

Marcus



--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 and test failures

Stéphane Ducasse
> 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


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 and test failures

Dale Henrichs

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


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 and test failures

Mariano Martinez Peck
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

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



Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 and test failures

Stéphane Ducasse
> 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.

really?
I'm confused then. :)

For me this is ok as it is. We should have a look at the configuration and probably review them not to load the latest version but for the rest this is ok.
And yes it requires some work because the configuration of a complex system over multiple versions is not simple.
Now symbolic versions are present and can help us.
Now if people are serious about pharo then they should read the metacello chapter for real because this is the way to work while the tools and process
emerge.
I cannot read it for people. Writing it is enough for me.



Stef

Metacello.pdf (570K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 and test failures

NorbertHartl
In reply to this post by Mariano Martinez Peck

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 <[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

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




Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 and test failures

laurent laffont
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 <[hidden email]> 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 <[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

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





Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 and test failures

otto
In reply to this post by NorbertHartl
> 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

+1 for option 3)  This also helps when a repository is down.