Clean up BFAV?
ducasse at iam.unibe.ch
Thu Jan 8 16:44:25 UTC 2004
> I spent some time along with Cees yesterday in trolling through old
> posts (which I've done a little of before) and find that I agree with
> Cees here. Most of the oldest posts are either
> 1. Already incorporated and should be closed anyway.
> 2. Irrelevant because the code in question either doesn't exist
> or has been changed significantly.
> 3. Incomplete threads missing enough information to understand the
> 3. Without the attachments the text of the messages is often
> insufficient to understand the issue. Code communicates but not when
> the code isn't there anymore.
> I'm not sure of where exactly to draw the line but 12/31/2002 and
> seems like as good a place as any. If the guides/harvesters will
> give the word I will put in what free time I can find into closing each
> one. For that matter I suppose a little code could be written to do
> job. I for one would prefer that they are closed and not moved
> elsewhere so that they are still available simply by choosing to view
> closed threads.
Thanks for your time. I agree with you but I will follow what doug says
if he has
another point of view. I'm sure not :).
I like the idea of daniel of following the tags as a mark. I'm also for
and moving it because moving mess does not sort it :).
Excellent so we will clean all that stuff.
> On Wed, 2004-01-07 at 19:14, Cees de Groot wrote:
>> I've been going through the backlog of BFAV, and most of the very old
>> posts are either:
>> - bad mails with no attachments;
>> - stuff that has been fixed.
>> Therefore I suggest that for everything prior to, say, Dec 31, 2002,
>> 1. Inform the original poster that this bug is going to be
>> 2. Close the bug.
>> The idea is that if the original author thinks the bug is still
>> worthwhile, he/she can resubmit it. This will let everyone concentrate
>> on stuff that is actually likely to work, BFAV will operate much
>> and in effect asks all 'affected' authors to do a review of their old
>> work. I think in light of the sheer size of the backlog this is an
>> entirely reasonable action.
>> (an alternative would be to move the old stuff to a separate archive,
>> make a special 'stalled' status you could select on).
More information about the Squeak-dev