Pharo 1.2 broken on Hudson due to XMLSupport changes

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

Pharo 1.2 broken on Hudson due to XMLSupport changes

Torsten Bergmann
Markus wrote:
>The XML package breaks the build? So let's remove it completely. Let's ship >1.2, but without all the packages that are problematic.

It's not that the package is problematic - the Configs are problematic

Laurent wrote:
>For XML I can fix this tonight if Otto don't want / can do it.

Yes, the problematic 1.1.8 version of XMLSupport has to be fixed.
But it is not yet used by Pharo ... so this is not the reason:

What strikes me is that ConfigurationOfPharo STILL references
the working 1.1.6 version BUT the corrupt 1.1.8 version is
loaded instead.
THIS is the reason why Hudson is read!

If you look at ConfigurationOfPharo then it hasnt changed
since 18 February 2011 (ConfigurationOfPharo-GuillermoPolito.134)
and if you load "ConfigurationOfXMLSupport-DaleHenrichs.46"
from 9 February 2011 and check what Otto Behrens changed
then you will notice that he did'nt touch the 1.1.6 version
of ConfigurationOfXMLSupport.

He just added a baseline/version 1.1.8 and 1.1.9.

So the "old" version 1.1.6 which is used by ConfigurationOfPharo
was not touched either.

To me this looks like a Metacello resolving remote project
versions problem? (that's why I CC:ed Dale)


>But I agree that it seems few people care about 1.2. Sad, I like it far
>better than 1.1.1.

Yes, but I think we opened 1.3 too early. I think thats
why community does not concentrate on Pharo dev 1.2 too much
and continues to work on 1.3 core instead.

Thats good for moving Pharo forward - but not for outside
visibility. How should others deliver software on top of Pharo
if Pharo isnt delivered itself?

>I personally thing if we ever want to release 1.2, we need to start to be >more radical.

Yes - but not by throwing out broken packages. What if Hudson
is broken by a problem in clas Object. Would you throw out Kernel?

Instead I would propose for the harvesters/integrators to stop
integrating stuff for 1.3 until Pharo 1.2 is out of the door...

Bye
T.
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 broken on Hudson due to XMLSupport changes

laurent laffont
On Fri, Feb 25, 2011 at 2:10 PM, Torsten Bergmann <[hidden email]> wrote:
Markus wrote:
>The XML package breaks the build? So let's remove it completely. Let's ship >1.2, but without all the packages that are problematic.

It's not that the package is problematic - the Configs are problematic

Laurent wrote:
>For XML I can fix this tonight if Otto don't want / can do it.

Yes, the problematic 1.1.8 version of XMLSupport has to be fixed.
But it is not yet used by Pharo ... so this is not the reason:

What strikes me is that ConfigurationOfPharo STILL references
the working 1.1.6 version BUT the corrupt 1.1.8 version is
loaded instead.

May be another ConfigurationOfXXXX reference XMLSupport ?


Laurent



 
THIS is the reason why Hudson is read!

If you look at ConfigurationOfPharo then it hasnt changed
since 18 February 2011 (ConfigurationOfPharo-GuillermoPolito.134)
and if you load "ConfigurationOfXMLSupport-DaleHenrichs.46"
from 9 February 2011 and check what Otto Behrens changed
then you will notice that he did'nt touch the 1.1.6 version
of ConfigurationOfXMLSupport.

He just added a baseline/version 1.1.8 and 1.1.9.

So the "old" version 1.1.6 which is used by ConfigurationOfPharo
was not touched either.

To me this looks like a Metacello resolving remote project
versions problem? (that's why I CC:ed Dale)


>But I agree that it seems few people care about 1.2. Sad, I like it far
>better than 1.1.1.

Yes, but I think we opened 1.3 too early. I think thats
why community does not concentrate on Pharo dev 1.2 too much
and continues to work on 1.3 core instead.

Thats good for moving Pharo forward - but not for outside
visibility. How should others deliver software on top of Pharo
if Pharo isnt delivered itself?

>I personally thing if we ever want to release 1.2, we need to start to be >more radical.

Yes - but not by throwing out broken packages. What if Hudson
is broken by a problem in clas Object. Would you throw out Kernel?

Instead I would propose for the harvesters/integrators to stop
integrating stuff for 1.3 until Pharo 1.2 is out of the door...

Bye
T.
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 broken on Hudson due to XMLSupport changes

EstebanLM
btw... 1.1.9 loaded well for me in 1.1.1 (while 1.1.8 was failing)

El 25/02/2011, a las 10:23a.m., laurent laffont escribió:

On Fri, Feb 25, 2011 at 2:10 PM, Torsten Bergmann <[hidden email]> wrote:
Markus wrote:
>The XML package breaks the build? So let's remove it completely. Let's ship >1.2, but without all the packages that are problematic.

It's not that the package is problematic - the Configs are problematic

Laurent wrote:
>For XML I can fix this tonight if Otto don't want / can do it.

Yes, the problematic 1.1.8 version of XMLSupport has to be fixed.
But it is not yet used by Pharo ... so this is not the reason:

What strikes me is that ConfigurationOfPharo STILL references
the working 1.1.6 version BUT the corrupt 1.1.8 version is
loaded instead.

May be another ConfigurationOfXXXX reference XMLSupport ?


Laurent



 
THIS is the reason why Hudson is read!

If you look at ConfigurationOfPharo then it hasnt changed
since 18 February 2011 (ConfigurationOfPharo-GuillermoPolito.134)
and if you load "ConfigurationOfXMLSupport-DaleHenrichs.46"
from 9 February 2011 and check what Otto Behrens changed
then you will notice that he did'nt touch the 1.1.6 version
of ConfigurationOfXMLSupport.

He just added a baseline/version 1.1.8 and 1.1.9.

So the "old" version 1.1.6 which is used by ConfigurationOfPharo
was not touched either.

To me this looks like a Metacello resolving remote project
versions problem? (that's why I CC:ed Dale)


>But I agree that it seems few people care about 1.2. Sad, I like it far
>better than 1.1.1.

Yes, but I think we opened 1.3 too early. I think thats
why community does not concentrate on Pharo dev 1.2 too much
and continues to work on 1.3 core instead.

Thats good for moving Pharo forward - but not for outside
visibility. How should others deliver software on top of Pharo
if Pharo isnt delivered itself?

>I personally thing if we ever want to release 1.2, we need to start to be >more radical.

Yes - but not by throwing out broken packages. What if Hudson
is broken by a problem in clas Object. Would you throw out Kernel?

Instead I would propose for the harvesters/integrators to stop
integrating stuff for 1.3 until Pharo 1.2 is out of the door...

Bye
T.
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de



Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 broken on Hudson due to XMLSupport changes

Stéphane Ducasse
In reply to this post by Torsten Bergmann

On Feb 25, 2011, at 2:10 PM, Torsten Bergmann wrote:

> Markus wrote:
>> The XML package breaks the build? So let's remove it completely. Let's ship >1.2, but without all the packages that are problematic.
>
> It's not that the package is problematic - the Configs are problematic

Exact
But still can't Pharo Dev focuses on tools and not frameworks that we should load by ourselves.
Because else why not loading, cassandra, coucdb, opendbx, magma....

Stef

>
> Laurent wrote:
>> For XML I can fix this tonight if Otto don't want / can do it.
>
> Yes, the problematic 1.1.8 version of XMLSupport has to be fixed.
> But it is not yet used by Pharo ... so this is not the reason:
>
> What strikes me is that ConfigurationOfPharo STILL references
> the working 1.1.6 version BUT the corrupt 1.1.8 version is
> loaded instead.
> THIS is the reason why Hudson is read!
>
> If you look at ConfigurationOfPharo then it hasnt changed
> since 18 February 2011 (ConfigurationOfPharo-GuillermoPolito.134)
> and if you load "ConfigurationOfXMLSupport-DaleHenrichs.46"
> from 9 February 2011 and check what Otto Behrens changed
> then you will notice that he did'nt touch the 1.1.6 version
> of ConfigurationOfXMLSupport.
>
> He just added a baseline/version 1.1.8 and 1.1.9.
>
> So the "old" version 1.1.6 which is used by ConfigurationOfPharo
> was not touched either.
>
> To me this looks like a Metacello resolving remote project
> versions problem? (that's why I CC:ed Dale)
>
>
>> But I agree that it seems few people care about 1.2. Sad, I like it far
>> better than 1.1.1.
>
> Yes, but I think we opened 1.3 too early. I think thats
> why community does not concentrate on Pharo dev 1.2 too much
> and continues to work on 1.3 core instead.
>
> Thats good for moving Pharo forward - but not for outside
> visibility. How should others deliver software on top of Pharo
> if Pharo isnt delivered itself?
>
>> I personally thing if we ever want to release 1.2, we need to start to be >more radical.
>
> Yes - but not by throwing out broken packages. What if Hudson
> is broken by a problem in clas Object. Would you throw out Kernel?
>
> Instead I would propose for the harvesters/integrators to stop
> integrating stuff for 1.3 until Pharo 1.2 is out of the door...
>
> Bye
> T.
> --
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 broken on Hudson due to XMLSupport changes

laurent laffont
On Fri, Feb 25, 2011 at 5:11 PM, Stéphane Ducasse <[hidden email]> wrote:

On Feb 25, 2011, at 2:10 PM, Torsten Bergmann wrote:

> Markus wrote:
>> The XML package breaks the build? So let's remove it completely. Let's ship >1.2, but without all the packages that are problematic.
>
> It's not that the package is problematic - the Configs are problematic

Exact
But still can't Pharo Dev focuses on tools and not frameworks that we should load by ourselves.
Because else why not loading, cassandra, coucdb, opendbx, magma....

Because many more people are manipulating  XML  every day than connecting to Cassandra ? 

Personnally I would like support for MySQL/PostreSQL out of the box too.

Laurent
 

Stef
>
> Laurent wrote:
>> For XML I can fix this tonight if Otto don't want / can do it.
>
> Yes, the problematic 1.1.8 version of XMLSupport has to be fixed.
> But it is not yet used by Pharo ... so this is not the reason:
>
> What strikes me is that ConfigurationOfPharo STILL references
> the working 1.1.6 version BUT the corrupt 1.1.8 version is
> loaded instead.
> THIS is the reason why Hudson is read!
>
> If you look at ConfigurationOfPharo then it hasnt changed
> since 18 February 2011 (ConfigurationOfPharo-GuillermoPolito.134)
> and if you load "ConfigurationOfXMLSupport-DaleHenrichs.46"
> from 9 February 2011 and check what Otto Behrens changed
> then you will notice that he did'nt touch the 1.1.6 version
> of ConfigurationOfXMLSupport.
>
> He just added a baseline/version 1.1.8 and 1.1.9.
>
> So the "old" version 1.1.6 which is used by ConfigurationOfPharo
> was not touched either.
>
> To me this looks like a Metacello resolving remote project
> versions problem? (that's why I CC:ed Dale)
>
>
>> But I agree that it seems few people care about 1.2. Sad, I like it far
>> better than 1.1.1.
>
> Yes, but I think we opened 1.3 too early. I think thats
> why community does not concentrate on Pharo dev 1.2 too much
> and continues to work on 1.3 core instead.
>
> Thats good for moving Pharo forward - but not for outside
> visibility. How should others deliver software on top of Pharo
> if Pharo isnt delivered itself?
>
>> I personally thing if we ever want to release 1.2, we need to start to be >more radical.
>
> Yes - but not by throwing out broken packages. What if Hudson
> is broken by a problem in clas Object. Would you throw out Kernel?
>
> Instead I would propose for the harvesters/integrators to stop
> integrating stuff for 1.3 until Pharo 1.2 is out of the door...
>
> Bye
> T.
> --
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de



Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 broken on Hudson due to XMLSupport changes

Marcus Denker-4
In reply to this post by Stéphane Ducasse

On Feb 25, 2011, at 5:42 PM, laurent laffont wrote:

On Fri, Feb 25, 2011 at 5:11 PM, Stéphane Ducasse <[hidden email]> wrote:

On Feb 25, 2011, at 2:10 PM, Torsten Bergmann wrote:

> Markus wrote:
>> The XML package breaks the build? So let's remove it completely. Let's ship >1.2, but without all the packages that are problematic.
>
> It's not that the package is problematic - the Configs are problematic

Exact
But still can't Pharo Dev focuses on tools and not frameworks that we should load by ourselves.
Because else why not loading, cassandra, coucdb, opendbx, magma....

Because many more people are manipulating  XML  every day than connecting to Cassandra ? 


So now XML is fixed, not it fails due to a problem in the Mock package...

We can not delay a release to fix all foreign packages. This makes no sense.

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 broken on Hudson due to XMLSupport changes

NorbertHartl

On 25.02.2011, at 17:48, Marcus Denker wrote:


On Feb 25, 2011, at 5:42 PM, laurent laffont wrote:

On Fri, Feb 25, 2011 at 5:11 PM, Stéphane Ducasse <[hidden email]> wrote:

On Feb 25, 2011, at 2:10 PM, Torsten Bergmann wrote:

> Markus wrote:
>> The XML package breaks the build? So let's remove it completely. Let's ship >1.2, but without all the packages that are problematic.
>
> It's not that the package is problematic - the Configs are problematic

Exact
But still can't Pharo Dev focuses on tools and not frameworks that we should load by ourselves.
Because else why not loading, cassandra, coucdb, opendbx, magma....

Because many more people are manipulating  XML  every day than connecting to Cassandra ? 


So now XML is fixed, not it fails due to a problem in the Mock package...

We can not delay a release to fix all foreign packages. This makes no sense.

Absolutely not. Otto did a mistake so this caused problems. So isn't it obvious to rollback the configuration back to the point it worked. 

Norbert

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 broken on Hudson due to XMLSupport changes

Guillermo Polito
I think the build will become unstable with every package update...  So maybe we should update every ConfigurationOf used by pharo, and put symbolic versions into it

Guille


On Fri, Feb 25, 2011 at 1:50 PM, Norbert Hartl <[hidden email]> wrote:

On 25.02.2011, at 17:48, Marcus Denker wrote:


On Feb 25, 2011, at 5:42 PM, laurent laffont wrote:

On Fri, Feb 25, 2011 at 5:11 PM, Stéphane Ducasse <[hidden email]> wrote:

On Feb 25, 2011, at 2:10 PM, Torsten Bergmann wrote:

> Markus wrote:
>> The XML package breaks the build? So let's remove it completely. Let's ship >1.2, but without all the packages that are problematic.
>
> It's not that the package is problematic - the Configs are problematic

Exact
But still can't Pharo Dev focuses on tools and not frameworks that we should load by ourselves.
Because else why not loading, cassandra, coucdb, opendbx, magma....

Because many more people are manipulating  XML  every day than connecting to Cassandra ? 


So now XML is fixed, not it fails due to a problem in the Mock package...

We can not delay a release to fix all foreign packages. This makes no sense.

Absolutely not. Otto did a mistake so this caused problems. So isn't it obvious to rollback the configuration back to the point it worked. 

Norbert


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 1.2 broken on Hudson due to XMLSupport changes

Marcus Denker-4
In reply to this post by NorbertHartl

On Feb 25, 2011, at 6:14 PM, Guillermo Polito wrote:

I think the build will become unstable with every package update...  So maybe we should update every ConfigurationOf used by pharo, and put symbolic versions into it


The 1.1 build is broken, too. So even for 1.1, we somhow load new packages, not the frozen ones.


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 broken on Hudson due to XMLSupport changes

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

On Feb 25, 2011, at 5:48 PM, Marcus Denker wrote:

Exact
But still can't Pharo Dev focuses on tools and not frameworks that we should load by ourselves.
Because else why not loading, cassandra, coucdb, opendbx, magma....

Because many more people are manipulating  XML  every day than connecting to Cassandra ? 


So now XML is fixed, not it fails due to a problem in the Mock package...

We can not delay a release to fix all foreign packages. This makes no sense.


I removed Mocketry for now... and the build works.



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