So, you want to move something "back" to Exceptions and will mean it's
the only class in that package, but it will remove one of several
dependencies on System -- as if there's something wrong with
MonticelloConfigurations depending on System..?

I must admit, I'm really confused about your motivations, Frank.

On Wed, Jul 24, 2013 at 5:35 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 23 July 2013 10:46,  <commits at source.squeak.org> wrote:
>> Frank Shearar uploaded a new version of Exceptions to project The Trunk:
>> http://source.squeak.org/trunk/Exceptions-fbs.48.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Exceptions-fbs.48
>> Author: fbs
>> Time: 23 July 2013, 10:43:57.584 am
>> UUID: ae58a39c-c2b3-f64f-8e96-f1e5b5d238e4
>> Ancestors: Exceptions-fbs.47
>>
>> Move Exceptions close to where they're used, rather than collecting them together just because they're Exceptions.
>>
>> =============== Diff against Exceptions-fbs.47 ===============
>>
>> Item was removed:
>> - Notification subclass: #ProgressNotification
>> -       instanceVariableNames: 'amount done extra'
>> -       classVariableNames: ''
>> -       poolDictionaries: ''
>> -       category: 'Exceptions-Kernel'!
>> -
>> - !ProgressNotification commentStamp: '<historical>' prior: 0!
>> - Used to signal progress without requiring a specific receiver to notify. Caller/callee convention could be to simply count the number of signals caught or to pass more substantive information with #signal:.!
>
> I'm seriously thinking of moving ProgressNotification back to
> Exceptions. It would be the only class in that package, but it would
> mean that MonticelloConfigurations would depend on Exceptions, not
> System. There are other things causing MonticelloConfigurations ->
> System, but this would remove one of them at least.
>
> frank
>