[update 1.4] #14355

>
> Issue 5325:     PackageInfo dependent on deprecated MethodReference
>        http://code.google.com/p/pharo/issues/detail?id=5325
>
>
>
>
> --
> Marcus Denker -- http://marcusdenker.de
>
>

> On Fri, Feb 24, 2012 at 2:55 PM, Marcus Denker <[hidden email]> wrote:
>> 14355
>> -----
>>
>> Issue 5338:     World menu icons are not updated when a default tool changes
>>        http://code.google.com/p/pharo/issues/detail?id=5338
>
> This fix adds dependency on Morphic to AppRegistry class >> #default
> so Pharo Kernel cannot be produced.
>
> Cheers
> -- Pavel

>
>>
>> Issue 5325:     PackageInfo dependent on deprecated MethodReference
>>        http://code.google.com/p/pharo/issues/detail?id=5325
>>
>>
>>
>>
>> --
>> Marcus Denker -- http://marcusdenker.de
>>
>>

> On Fri, Feb 24, 2012 at 3:37 PM, Pavel Krivanek
> <[hidden email]> wrote:
>> On Fri, Feb 24, 2012 at 2:55 PM, Marcus Denker <[hidden email]> wrote:
>>> 14355
>>> -----
>>>
>>> Issue 5338:     World menu icons are not updated when a default tool changes
>>>        http://code.google.com/p/pharo/issues/detail?id=5338
>>
>> This fix adds dependency on Morphic to AppRegistry class >> #default
>> so Pharo Kernel cannot be produced.
>>
>> Cheers
>> -- Pavel
>
> http://code.google.com/p/pharo/issues/detail?id=5370
>
> -- Pavel
>
>>
>>>
>>> Issue 5325:     PackageInfo dependent on deprecated MethodReference
>>>        http://code.google.com/p/pharo/issues/detail?id=5325
>>>
>>>
>>>
>>>
>>> --
>>> Marcus Denker -- http://marcusdenker.de
>>>
>>>
>

>
> On Feb 25, 2012, at 5:20 PM, Stéphane Ducasse wrote:
>
>> Excellent!
>> Pavel
>> We should add Pharo Kernel as dependent of the head so that we get immediate feedback like that.
>> because this is really great.
>>
>
> It already is configured to be build after every update:
>
>        https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%201.4/
>
> tests, too:
>
>        https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%20Tests/
>
> Now we need to take action when it breaks...

> On Sat, Feb 25, 2012 at 5:28 PM, Marcus Denker <[hidden email]> wrote:
>>
>> On Feb 25, 2012, at 5:20 PM, Stéphane Ducasse wrote:
>>
>>> Excellent!
>>> Pavel
>>> We should add Pharo Kernel as dependent of the head so that we get immediate feedback like that.
>>> because this is really great.
>>>
>>
>> It already is configured to be build after every update:
>>
>>        https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%201.4/
>>
>> tests, too:
>>
>>        https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%20Tests/
>>
>> Now we need to take action when it breaks...
>
> Of course it is always much better if the author of the patch can see
> that it caused some problem than when some other person must later
> investigate what patch of an update has evil side effect.
>
> I hardly need to tell you that it is very demotivating to wait what
> next will break something again (as this week one single update fixed
> one issue and brought the next one). Instead of improving of the
> system we must spend a lot of energy on maintenance.
>
> We definitely must improve the QA process.

> On Sat, Feb 25, 2012 at 10:13 PM, Pavel Krivanek
> <[hidden email]> wrote:
>> On Sat, Feb 25, 2012 at 5:28 PM, Marcus Denker <[hidden email]> wrote:
>>>
>>> On Feb 25, 2012, at 5:20 PM, Stéphane Ducasse wrote:
>>>
>>>> Excellent!
>>>> Pavel
>>>> We should add Pharo Kernel as dependent of the head so that we get immediate feedback like that.
>>>> because this is really great.
>>>>
>>>
>>> It already is configured to be build after every update:
>>>
>>>        https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%201.4/
>>>
>>> tests, too:
>>>
>>>        https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%20Tests/
>>>
>>> Now we need to take action when it breaks...
>>
>> Of course it is always much better if the author of the patch can see
>> that it caused some problem than when some other person must later
>> investigate what patch of an update has evil side effect.
>>
>> I hardly need to tell you that it is very demotivating to wait what
>> next will break something again (as this week one single update fixed
>> one issue and brought the next one). Instead of improving of the
>> system we must spend a lot of energy on maintenance.
>>
>> We definitely must improve the QA process.
>
> To support my lemmenting I must say that the state of non-failing
> kernel jobs lasted only 10 hours. :-)
>
> -- Pavel
>

>> Of course it is always much better if the author of the patch can see
>> that it caused some problem than when some other person must later
>> investigate what patch of an update has evil side effect.
>>
>> I hardly need to tell you that it is very demotivating to wait what
>> next will break something again (as this week one single update fixed
>> one issue and brought the next one). Instead of improving of the
>> system we must spend a lot of energy on maintenance.
>>
>> We definitely must improve the QA process.
>
> To support my lemmenting I must say that the state of non-failing
> kernel jobs lasted only 10 hours. :-)

>
>>> Of course it is always much better if the author of the patch can see
>>> that it caused some problem than when some other person must later
>>> investigate what patch of an update has evil side effect.
>>>
>>> I hardly need to tell you that it is very demotivating to wait what
>>> next will break something again (as this week one single update fixed
>>> one issue and brought the next one). Instead of improving of the
>>> system we must spend a lot of energy on maintenance.
>>>
>>> We definitely must improve the QA process.
>>
>> To support my lemmenting I must say that the state of non-failing
>> kernel jobs lasted only 10 hours. :-)
>
> Excellent! :)
> Seriously it means that we should work on rules checking so that we identify the violations.
> People used tests for that now as soon as we have small lint we should be able to express architecture rules.
>
> Stef
>
>
>