Idea: "Timeout" submissions?

Daniel Vainsencher danielv at netvision.net.il
Fri Oct 3 14:42:08 UTC 2003


The reason bug reports get ignored is not that the tools are wrong, it
is that they have no actionable meaning. In Debian, a package with RC
bugs cant get promoted to testing, and therefore can't become part of a
release. Since we don't have levels, and a lot of code is in the image
already, there is nothing to do about the bug. The buggy code cannot be
easily removed from the image.

We have a system in place for dealing with bug fixes, so while it is
underpowered, it does deal with some things.

But there is no system for dealing with bug reports, and therefore they
are systematically ignored. The only thing that effectively happens with
bug reports is that if someone else happens to care/know about the bug
when it is posted, and has time, it might turn into a bug fix. As far as
I know, nobody bothers to ever [closed] bug reports, because they don't
bother anyone anyway - nobody is looking at them.

The only kinds of bug reports that matter even a little bit in the long
run are those that have SUnit tests. Marcus harvests those, and the test
server tests those, so the community gets feedback on whether those are
still broken or not. That's still only in startup stages, because we
haven't had any fixes turned into updates yet, so the broken tests
haven't changed (which is why I'm not bothering to post them until some
updates come out). 

I think we can simply delete the whole bugs archive, and nobody will
actually notice.

Daniel

Lex Spoon <lex at cc.gatech.edu> wrote:
> Marcus Denker <marcus at ira.uka.de> wrote:
> > The squeak community currently ignores *every* bugreport. Just if someone
> > happens to have some time on his hand just at the exact moment someone files
> > the report something happens. I would estimate that a bug-report that is
> > not fixed within 48h is forgotten.
> 
> This shouldfn't be true if we really have a "bug archive viewer".  It's
> certainly very far from true for Debian packages.  Some of them have
> staggering numbers of bug, but the old ones still don't get forgotten.
> 
> Granted, even large Debian packages tend to have less in them than
> Squeak as a whole....
> 
> 
> > Perhaps the hardest part of a bug archive system (in my tediously long
> > experience of them) is finding a way to connect related reports. Using
> > email-like threading is an excellent start but we really need to filter
> > them through a context sensitive AI engine to correlate with older
> > reports. Actually, we ought to do that with the entire mailing list so
> > that threading is done properly.
> 
> Whether there is AI or not, there should be a mechanism for combining
> and detaching individual posts to a bug log.  If the AI gets it wrong,
> we will want a chance to correct it.  Further, even without an AI, we
> can get along fairly well by just having a way to combine them.
> 
> All it takes is two new message types: "merge" and "split".  Merge has
> two arguments, and split has just one.  The polite thing to do after a
> split, would be to note which thread corresponds to which part of the
> bug report.
> 
> I guess there could be "unmerge", as well.
> 
> -Lex



More information about the Squeak-dev mailing list