Re: [Pharo-project] [update 1.4] #14355
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... -- Marcus Denker -- http://marcusdenker.de
On Sat, Feb 25, 2012 at 5:28 PM, Marcus Denker <marcus.denker@inria.fr> 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. -- Pavel
-- Marcus Denker -- http://marcusdenker.de
On Sat, Feb 25, 2012 at 10:13 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
On Sat, Feb 25, 2012 at 5:28 PM, Marcus Denker <marcus.denker@inria.fr> 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
-- Pavel
-- Marcus Denker -- http://marcusdenker.de
On Sat, Feb 25, 2012 at 10:45 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
On Sat, Feb 25, 2012 at 10:13 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
On Sat, Feb 25, 2012 at 5:28 PM, Marcus Denker <marcus.denker@inria.fr> 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
hmm, this failure of Pharo Kernel Tests has interesting reason. It fails because in the package CompilerTests there is one class (CustomParserTest) that uses customParser. The custom parser class is present in the same package but its definition follows its usage. It seems that it is not related to a single update but it is caused by an accidental order in *.st file from the mcz archive. So it may disappear with the next commit of the CompilerTests package. -- Pavel
-- Pavel
-- Marcus Denker -- http://marcusdenker.de
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
Wouldn't something simplistic like squeak PackageDependencyTest help? Nicolas Le 26 février 2012 09:58, Stéphane Ducasse <stephane.ducasse@inria.fr> a écrit :
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
participants (4)
-
Marcus Denker -
Nicolas Cellier -
Pavel Krivanek -
Stéphane Ducasse