On Sat, Feb 25, 2012 at 10:45 PM, Pavel Krivanek <[email protected]> wrote: > On Sat, Feb 25, 2012 at 10:13 PM, Pavel Krivanek > <[email protected]> wrote: >> On Sat, Feb 25, 2012 at 5:28 PM, Marcus Denker <[email protected]> >> 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 >>> >>>
