[Pharo-dev] [Pharo-bugtracker] FogBugz (Case [Issue]2486) File System - Linux VM: Umlaute äöÜ etc in in file/directory names: UTF8 unicode problem?

Camillo Bruni camillobruni at gmail.com
Sun Nov 10 08:25:01 EST 2013

> That would seem to be a lot of additional work for the monkey, which might not be a problem if the set of Cases is small or CPU resources are high.
> Perhaps the process could be amended so the monkey operates in two stages.  
> 1. In taking the status from "Fix review needed" to "Fix Reviewed by the Monkey" - the monkey runs once and does not run again.
> 2. When a human comes along and changes the status to "Fix to include", the monkey runs again, and also for each image update until integrated.  The status would not change from "Fix to include".
> Optionally Step 2 could also...
> 2a. In consideration of how several fixes are usually integrated in one image step, the monkey could consecutively load several Fixes on top of the previous image step, to check for incompatibilities between Fixes, and advise the human integrator of a known good order of integration; OR...
> 2b. A successful monkey test of "Fix to Include" automatically kicks off a CI run on that Fix.   So that you end up with one Fix per image step.  Probably this doubles up on the CI test run, but should ensure the CI never goes red; OR...
> 2c. A combination of 2a & 2b.  The monkey loads several "Fix to Include" Fixes until there is a problem, and copies all the good ones to kick off a CI run.
> So I know that would require some effort, but just food for thought.  I'd be interested in helping do this.

The noise is some side-effect of the current somewhat limited situation. In the ideal case
the monkey would just attach a new tag for each new image version if the validation report
did not change. But for that you need to have your own complete service which keeps track
of the previous validations. As you can imagine this will take some time and effort ;)

For now I think we stick with the current approach which is more noisy but safer.
Everybody is of course invited to improve the situation:



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 447 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131110/ffd0ab96/attachment.asc>

More information about the Pharo-dev mailing list