2018-08-16 14:51 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:

Hi Edgar,
First, I see no such sender of #soundsEnabled in base image, so it's more a problem of uncompatibility with add-on packages (extensions) than a problem of base image, right?

Then, thanks to commit messages in the mailing list, I can trace that Preferences class>>#soundsEnabled - which is a EToys thing - was added in Trunk: System-tfel.902.mcz (which itself is a merge with System-tfel.882).

But unfortunately, I can't easily trace when this message was removed in favour of a doesNotUnderstand: solution...
Maybe it was removed at a time when the mailing list reports were not functional?
Or maybe, the changes were not reported because too long...
(That's a bad feature IMO, on the assumption that code should never be too long, we should not need any such guard anyway...).

Nope,

it's because the change (the removal of Preferences class>>#soundsEnabled ) happened in a version not commited in trunk.

then the change was not reported from

Name: System-tfel.911
Author: tfel
Time: 29 August 2016, 4:20:07.411946 pm
UUID: 0242c0ab-04df-994a-adb2-a8c26da259fa
Ancestors: System-tfel.902, System-ul.910

because only the diff to more recent System-ul.910 is shown in mailing list...

The thing to do before/after loading such EToys like extension is to perform Etoys like initialization, and that could well be a responsibility of extension code, rather than of base image. So maybe it's not a problem of Trunk by itself...
The question is how do we advertize the package maintainers about these new responsibilities caused by evolutions of Trunk (understand evolution as shrinking/simplifying)?