From: Thien-Thi Nguyen <ttn@giblet.glug.org>
Cc: mvo@zagadka.ping.de, guile-devel@gnu.org
Subject: Re: More Bug Stuff
Date: Thu, 28 Mar 2002 20:02:17 -0800 [thread overview]
Message-ID: <E16qnaj-0001Sv-00@giblet> (raw)
In-Reply-To: 871ye4y6qq.fsf@tyrell.bad-people-of-the-future.san-francisco.ca.us
From: Evan Prodromou <evan@glug.org>
Date: Thu, 28 Mar 2002 10:52:45 -0600
It's much easier to auto-generate a unique number than a meaningful
unique symbolic name.
if it's not easier it's more fun to write, no?
It makes writing parsers easier. Do you really need the flexibility of
using ANY kind of address header?
i don't understand you. to me, using ANY instead of some other
complicated syntax is the most flexible, for other tools.
It makes it much easier to say things like this: [...]
I'm a little confused why you say that priority assignment is "mostly
arbitrary"[...]
probably mvo means this kind of scheme is fine to set up, but not in the
bugs database. prioritization is larger in scope than bugs handling and
generally prioritization schemes are never universal (among humans).
this would be a good time to suggest that render-bugs in the future also
handle small writes to the db (rendering it more like "edit-bugs"), such
as maintaining a "priority: ((WHO N) ...)" header.
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.
Anyways, OK, the rest looks good.
you're overspecifying, dude. c'mon man! first get the core done so we
can jump in w/ passing around higher order functions and all that good
stuff. separate mechanism and policy and post something elegant.
[insert small steps rant.]
(sorry, i have been -er- wafting some vapors of late.)
thi
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2002-03-29 4:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-24 20:23 More Bug Stuff Evan Prodromou
2002-03-24 23:03 ` Marius Vollmer
2002-03-25 8:21 ` Thien-Thi Nguyen
2002-03-25 15:48 ` Rob Browning
2002-03-25 21:19 ` Thien-Thi Nguyen
2002-03-25 21:35 ` Marius Vollmer
2002-03-25 22:00 ` Thien-Thi Nguyen
2002-03-25 22:03 ` Thien-Thi Nguyen
2002-03-25 22:25 ` Marius Vollmer
2002-03-27 0:31 ` Evan Prodromou
2002-03-27 2:58 ` Thien-Thi Nguyen
2002-03-27 19:09 ` Marius Vollmer
2002-03-27 20:39 ` Thien-Thi Nguyen
2002-04-07 11:17 ` Marius Vollmer
2002-04-07 19:05 ` Thien-Thi Nguyen
2002-04-07 21:22 ` Thien-Thi Nguyen
2002-04-07 21:38 ` Marius Vollmer
2002-03-27 18:56 ` Marius Vollmer
2002-03-28 16:52 ` Evan Prodromou
2002-03-29 4:02 ` Thien-Thi Nguyen [this message]
2002-04-07 12:03 ` Marius Vollmer
2002-04-07 22:22 ` Thien-Thi Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E16qnaj-0001Sv-00@giblet \
--to=ttn@giblet.glug.org \
--cc=guile-devel@gnu.org \
--cc=mvo@zagadka.ping.de \
--cc=ttn@glug.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).