Idea: "Timeout" submissions?

Richard A. O'Keefe ok at cs.otago.ac.nz
Thu Oct 2 11:48:42 UTC 2003


Marcus Denker <marcus at ira.uka.de> proposes automatically
deleting bug fixes that have not been harvested.
	1) remove clutter from the Archive
	2) We have a third way to decide about changes: "yes" "no" and
	   "nobody cares, thus: no".
	3) The image is a moving target. Especially refactorings tend
	   to change lots of methods, and old fixes rot. This way we
	   make sure that we only have to harvest changes that are
	   reasonably old.
	4) Maybe this will help to bring some urgency into harvesting
	   "I need to get this in or it will be lost". 
	
	Any negative effects? 
	
Yes.  It amounts to taking items that should have high priority
(because they have been waiting for a long time) and saying "nyaa nyaa,
WON'T!"

This will only remove clutter from the Archive if old fixes are
clutter.  I see no reason to believe that, considering how long some
bugs have been in the system.

There is the completely false assumption that "nobody responds to the
deletion" means the same as "nobody cares".  I for one am completely
snowed under with e-mail; I routinely delete BugFix messages after
only the most cursory skimming.  For the next couple of weeks I expect
to be extremely busy indeed, and I shall have to skim my mail at the
highest speed I can manage.  That doesn't mean I won't _care_ if any
fixes I've submitted are spat into the wastebin, it means that I won't
_know_.

The fact that old fixes "rot" is precisely why they should be given
the highest priority and cleaned up before new fixes are put in.
The absence of a fix can occasionally give a false impression about
what can be done to the rest of the system.  Just because a fix hasn't
been *harvested* doesn't mean it isn't being *used*.

I don't see this change bringing any urgency into harvesting.
A rather more typical human response will be "if I don't bother with
this it will go away".



More information about the Squeak-dev mailing list