Idea: "Timeout" submissions?

Daniel Vainsencher danielv at netvision.net.il
Tue Oct 7 16:44:53 UTC 2003


> 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. 
You see, that's the thing I don't believe. I think we need to have a
sketch of a process with people making decision that take bugs into
account, and then find the tool to serve those people in making those
decisions. If we don't know what value we want to get from the bug
process, choosing a tool won't help.

Daniel


Lex Spoon <lex at cc.gatech.edu> wrote:
> 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