Idea: "Timeout" submissions?

Lex Spoon lex at cc.gatech.edu
Tue Oct 7 17:05:10 UTC 2003


Daniel Vainsencher <danielv at netvision.net.il> wrote:
> Lex Spoon <lex at cc.gatech.edu> wrote:
> > It requires a little bit of tool support. 
> Wait wait - before we run off to choose tools - what is "it"? what is
> supposed to happen with bug reports? who will look at them, when, and
> what decisions will be made? Lets first decide the process, then 
> mechanize it.
> 
> I know what happens to Debian bugs, package get automatically kept out
> of integration. What will happen in Squeak?
> 

I don't remember if I posted this, but Joel on Software has an excellent
short article about bug report management.  Most bug trackers will
support most any reasonable process we come up with, I expect.

	http://www.joelonsoftware.com/articles/fog0000000029.html

I'm sure people can find much better articles.


To answer your questions one by one.

"What is supposed to happen with bug reports".  First, they are
remembered.  Second, they have an overall status which is also
remembered.  In particular, you can tell if a bug is open or closed, and
you can retrieve a list of bugs that are currently open.  Ideally, you
can retrieve a list of bugs that are related to some portion of the
system, e.g. the Morphic kernel, or the compiler.

"Who will look at them".  Everyone.  :)  Okay, this is a serious issue
and we need an answer that makes sense for Squeak.  We need to know who
is going to keep track of bugs regarding various issues.  Debian's
answer is that every package has a designated maintainer, and every bug
is assigned to a package.  Thus every bug is reviewed at least by the
maintainer of the package the bug is assigned to.  We could eventually
do something like this for Squeak.  For now, just having a global list
is much better than nothing.

"When will they look at them".  Whenever they have time...

"What decisions will be made".  They will decide if the bug is real or
not; a non-real bug could either be the expected behavior, or it could
be that it's not Squeak that is at fault.  Assuming it's real, they will
begin working towards a fix.  This can take a large variety of
mechanisms, including trying to fix it themselves and trying to find
someone else who knows how to fix it.  Finally, someone will need to
decide when the bug has been fixed, and then mark it as such.



"I know what happens to Debian bugs, package get automatically kept out
of integration. What will happen in Squeak?"  I vote that nothing
happens.  Debian has a horrendous time with each release because of its
policy.  (And by the way, it's even a little weaker than you've stated
it.  It's only the severe bugs that keep a release from including a
package; minor bugs are okay.)


Anyway, again, I don't think we will have trouble adapting any process
we please to almost any bug tracking tool.  In the short term, if we
simply change from emailing [BUG] reports and start using a web-based
bug tracker, we will immediately come out ahead of where we are now. 
And the stage will be set for more sophisticated bug-management
processes if anyone wants to bother working it out.  :)


-Lex



More information about the Squeak-dev mailing list