I think we should have a massive bug fixing "party" 
and see how long it would take to go through 
the list of standing bug and fixes.
If we could get 20-30 people going at this for a few
hours it would give some impressive results, and the list would
dwindle.
I would love to contribute, but I cant get the darn 
BFAV to run on my machine ;-)

Karl

Hernan Tylim wrote:
> 
> Hi,
>         As a person who has sent a fix for a still current bug twice, and didn't
> receive a comment in either oportunity (at least stating that my fix was
> wrong or sucked) I have something to say.
> 
>         I think that BFAV should priorize the oldest items by default. And also,
> though it might have changed by now, when I used the BFAV to submit these
> fixes I saw that BFAV only downloaded the latest 500 entries in the Archive,
> so you already have a timeout filter there, and I think that's a bad thing.
> 
>         If the timeout filter idea persist, I suggest that an automatic email
> notifying the fix's author should be the polite thing to do.
> 
> disclaimer: I am a little rough with my english, so if my message sounded a
> little harsh please forgive me. I am not criticizing just only giving my 2
> cents
> 
> Regards
> Hernán
> 
> > -----Mensaje original-----
> > De: squeak-dev-bounces at lists.squeakfoundation.org
> > [mailto:squeak-dev-bounces at lists.squeakfoundation.org]En nombre de
> > Daniel Vainsencher
> > Enviado el: Jueves, 02 de Octubre de 2003 10:07
> > Para: The general-purpose Squeak developers list
> > Asunto: Re: Idea: "Timeout" submissions?
> >
> >
> > Seems to me we could have the same effect with less work by having a
> > "time window filter" in the BFAV that shows only the last years posts.
> > That would make it easy both to do the regular harvesting/reviewing, but
> > also to go fishing for oldies.
> >
> > What would change in essence is only that we'd be saying that the
> > harvester generally look only at the stuff that either recent or
> > recently touched. Which I think would reasonable...
> >
> > Daniel
> >
> > Marcus Denker <marcus at ira.uka.de> wrote:
> > > Hi,
> > >
> > > I am cleaning up the Bugfix-Archive a little, so that we actually have a
> > > chance to look at the stuff that's there.
> > >
> > > While doing this I had an idea, and it would be interesting to know
> > > if this would be of some value.
> > >
> > > Up to now we just stuff all bugs into the archive, and there it
> > > is kept until the case is either [closed] or [approved]. Closing
> > > can happen due to a lot of different causes (rejected, allready
> > > included, superseded, not for the image, and so on).
> > >
> > > Nevertheless we have acumulated a *huge* backlog of Fixes and
> > > Enhancements that nobody has looked at till now.
> > >
> > > I would like to have a clearly defined strategy how to handle
> > > this. And my Idea would be that *every* item, regardless of how
> > > cool or important it is, gets closed after 6 Months "automatically".
> > > This actually don't need to be really automatic: Just if a harvester
> > > happens to see a an old item in BFAV he either harvests it or just
> > > sends a [closed] message.
> > >
> > > The idea is that *really* important changes will be re-submitted by
> > > someone (the author, a user, just someone who cares about it). The
> > > re-submitted fix will have to be tested and adjusted for the latest
> > > development-image.
> > >
> > > So this scheme will habe a lot of good effects:
> > >
> > > 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?
> > >
> > >     Marcus
> > >
> > >
> > > --
> > > Marcus Denker marcus at ira.uka.de  -- Squeak! http://squeak.de