We should run + fix the tests in 1.1

> Stéphane Ducasse wrote:
>> ... testserver, where are you?
>
> I have:
>
>     http://hudson.jooshr.org/job/Pharo1.1/
>
> which builds once a day. There are other builds on the site. I only use
> the Pharo1.0-Seaside3.0 configuration. The others were set up when I was
> trying to decide what to base my development on.
>
> The builds often break (Pharo 1.1 and Seaside 3.0), which is to be
> expected. Usually the problem is some dialog pops up waiting for a user
> response. It often takes me a few days before I get around to fixing
> these build problems. Anyhow, it's there for the moment, if people want
> to use the results.
>
> --
> Yanni
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Mariano Martinez Peck wrote:
>> I thought we killed all those tests that brings a popup and wait for a
>> user response.
>>
>> Yanni can you tell us which are those tests ?
>
> There are some tests that I filtered out, and don't run, because they
> stopped the build. That was a few weeks ago. You can see which ones, by
> looking at:
> http://hudson.jooshr.org/job/Pharo1.1/ws/core11-tests/core11-tests.st/*view*/
>
> where you'll find:
>
> HDTestReport
>   runClasses: (
>     TestCase withAllSubclasses reject: [:cls |
>       ((cls category asString beginsWith: 'Tests-Traits')
>         or: [cls name = 'ImageSegmentTestExport'])
>         or: [cls name = 'MCPackageTest']
>     ]
>   )
>   named: 'AllTestCases'
>
> At some point, I'll run these disabled tests to see how they're behaving
> now.
>
> The latest problem, from a few days ago, was that Object>>displayExtent
> was deprecated (maybe it wasn't called displayExtent, but something like
> that). I eventually added:
>
>     Preferences disable: #raiseDeprecatedWarnings.
>
> so the build would continue in a headless image.
>
> Prior to that, the Author name was no longer automatically set for
> SUnit. That was solved with:
>
>     Author fullName: 'builder'.
>
> And before that, some updates caused a dialog to pop up (maybe it was
> the deprecation dialog, I can't remember). That was solved with:
>
>     [Utilities updateFromServer] valueSuppressingAllMessages
>
> It seems that something always happens. Just have to fix them as they
> come along, or hope that everyone runs a headless build and sees the
> problem and fixes it right away.
>
> --
> Yanni
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> my experience is similar to Yanni, in that I found a series of
> updates, every so often, would break the build.  it became a pain to
> keep on checking and fixing things.  So i am spending my time on
> trying to script some sanity checks and logic for common errors. Given
> the pace of updates, whilst human intervention is the simple solution,
> i don't think it is great.  One gets behind very quickly.
>
> Also, how many developers regularly look at the test result pages (the
> first version on the wiki, the gforge /experimental, yanni's hudson
> setup) for the core image and act on the implied bugs in the update?
> i.e comment on the issue tracker related to the specific update just
> published
>
> I think we need to email the delta of each test run to this mailing
> list as soon as it is run.