On 7 April 2018 at 04:20, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> Hi David,
> Just a small brook for washing yet another
> https://en.wikipedia.org/wiki/Labours_of_Hercules#Fifth_labour:_Augean_stables
> ;)
>
> My advice would be to inspect the entries updated these last two years, and
> if still relevant confirm (or fix) else close.
> Fortunately, there are not so much of them.
>
> Then I would close all the rest (resolution = timeout).
> Other teams including Pharo have such a policy.

Note that this is done by a bot, so there is no judgement of the
importance of the issue.
The judgement comes from the initiator re-opening it.

>
> Generally, I hate when my opened issues are closed like that, because I
> mostly don't use Pharo, so I consider these as pure gifts.
> There is a side effect that I'm not encouraged to report anymore, and I
> rarely reopen them, because I have no time to check.
> There is no such thing as gift-support-service.

Personally, when my Pharo issues are auto-closed
sometimes I think "Whoops, I really do mean to get back to that" and re-open it,
and othertimes I think "Nah! It never happened to me twice, not
*really* important" and I leave it closed.
The latter doesn't discourage me from logging issues.  Its there to be
found if its a common issue
and it gains additional comments indicating it should be reopened if
no-one yet dealt with it.

cheers -ben

>
> But, in the end, Pharo team is right: accumulation of rotten issues is not
> sustainable
> - either the issue is important, and it must/will be reopened
> - or no one cares and the issue can be closed.

>
> If Heracles himself wants to inspect and resolve the timed-out issues, he
> would just have to set a filter with a few clicks.
> But there's no hurry, the Augean stables had to wait 30 years...
>
> 2018-04-06 21:58 GMT+02:00 David T. Lewis <lewis at mail.msen.com>:
>>
>> Nicolas,
>>
>> It is really good to see those Mantis issues being addressed. Thank you!
>>
>> Dave
>>
>> > Hi Marcel, Tobias,
>> > I encountered a bug, when playing a sound, the default SoundService
>> > (class
>> > inst var) was not a class (BasedSoundService) but an instance (a
>> > BasedSoundService).
>> >
>> > Why?
>> > Because, there is a TileMorphTest>>setUp that remember which is the
>> > default, then tries to restore it in tearDown.
>> > It used to work.
>> >
>> > But, in between, SoundService default and defaultOrNil have been
>> > re-defined
>> > so as to answer an instance rather than a class.
>> >
>> > Thus, when we play the tests, we can no more play the sounds...
>> >
>> > I hesitate to open a Mantis issue, no one read nor close them, so the
>> > bug
>> > report is only here for the moment.
>> >
>> >
>>
>>
>>
>
>
>
>