From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: More Bug Stuff Date: 07 Apr 2002 14:03:41 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <87zo0f1zs2.fsf@zagadka.ping.de> References: <873cypn2a2.fsf@tyrell.bad-people-of-the-future.san-francisco.ca.us> <87d6xtzhzv.fsf@zagadka.ping.de> <871ye4y6qq.fsf@tyrell.bad-people-of-the-future.san-francisco.ca.us> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1018181005 26434 127.0.0.1 (7 Apr 2002 12:03:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 7 Apr 2002 12:03:25 +0000 (UTC) Cc: guile-devel@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16uBOG-0006sF-00 for ; Sun, 07 Apr 2002 14:03:24 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16uBNv-0003GW-00; Sun, 07 Apr 2002 08:03:03 -0400 Original-Received: from dialin.speedway42.dip219.dokom.de ([195.138.42.219] helo=zagadka.ping.de) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16uBLj-00030o-00 for ; Sun, 07 Apr 2002 08:00:47 -0400 Original-Received: (qmail 1511 invoked by uid 1000); 7 Apr 2002 12:03:41 -0000 Original-To: Evan Prodromou In-Reply-To: <871ye4y6qq.fsf@tyrell.bad-people-of-the-future.san-francisco.ca.us> Original-Lines: 102 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:319 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:319 Evan Prodromou writes: > >>>>> "MV" == Marius Vollmer writes: > > MV> Do we need a number? I'd rather go with a symbolic name. > MV> Numbers are so, umm, 'C'. > > It's much easier to auto-generate a unique number than a meaningful > unique symbolic name. OK, we can have both. > Me> Name and email address of person who reported the bug, in > Me> angle-bracket format. > > MV> Do we need to restrict us to the angle bracket format? What > MV> about allowing any RFC2822 mailbox? > > It makes writing parsers easier. Do you really need the flexibility of > using ANY kind of address header? It would make it easier to paste addresses from mails, and we would have a way to specify a real name. Do we actually need to parse the mailbox string for simple tasks? > >> * Priority (0,Inf) > > MV> Again, do we need hard numbers for this? In general, I think > MV> it will be mostly arbitrary what priority number is assigned > MV> to a bug. > > It makes it much easier to say things like this: "For the next beta, > we will fix all priority 1 bugs and as many 2 and 3 bugs as we can." Yes, but is this a useful thing to say? This will depend on how people will assign priorities and whether something gets a "1" or a "2" will be mostly arbitrary, I think, and consequently what bugs get fixed for the beta will be arbitrary as well. If you see it the other way around, as: "If you want the bug fixed for the next beta, assign it a priority of 1, else chose some larger number", then it will limit the meaning of the priority field to one specific task (in this case the releasing of the next beta). And after the beta is out, will we reprioritize the bugs? Anyway, I don't really need to understand the importance of a priority field. We can have it, as long as its optional. > I'm a little confused why you say that priority assignment is "mostly > arbitrary". The numbers themselves don't mean anything, so when you need to chose a priority for a bug you'll pick a number that you feel expresses your idea of the bugs priority. Other people will chose different numbers although they might want to express the same idea of priority. > First off, you've set yourself up as the arbitrator, so that's about > right. The system needs to work without a central arbiter. > MV> Identifying critical bugs, and distinguishing bugs > MV> from wishlist items is important, tho. We can use Severity > MV> for this. > > Hurgh. I knew this would come up. Did you read what I wrote about > Severity vs. Priority? Yes. > Me> NOTE that Priority and Severity are loosely coupled -- things > Me> that are more severe usually will have a high priority, but not > Me> necessarily. For example, updating the version string for a > Me> release is a high priority task, but it's not particularly > Me> severe (it'd be a nuisance). When a release is out with a wrong version number, I would call that pretty severe! (The mere task of updating the version number before a release would not be recorded as a bug.) > MV> Are we talking about tasks here as well, in addition to bugs? > MV> For tasks, priority makes more sense. > > Sorry, I mistakenly used the word "task" here, which seems to have > confused you. What I should have said was "piece of work." If a > release went out with the FSF address misspelled, this would be a low > _severity_ bug, but a high _priority_ one. How can it be severe and still have low priority? It seems I don't get it. Anyway, don't let this stop you from adding a optional priority field. [ To be super pedantic: a bug can meaningfully have a severity associated with it, but no priority. A bug is the description of an existing behavior, but not a description of a piece of work that needs to be carried out. Each bug has implicitly associated with it the task of fixing it, and that task can have a priority. But this priority is, in my view, not really meaningfully expressible with some hard and fast number. I.e., what has low priority for me might have a high priority for you. ] _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel