From: Thien-Thi Nguyen <ttn@giblet.glug.org>
Cc: mvo@zagadka.ping.de, guile-devel@gnu.org
Subject: Re: Tool version in HACKING
Date: Tue, 09 Apr 2002 23:29:52 -0700 [thread overview]
Message-ID: <E16vBc8-0006ne-00@giblet> (raw)
In-Reply-To: <200204091928.MAA18069@onyx.he.net> (message from Gary Houston on 9 Apr 2002 20:28:25 +0100)
From: Gary Houston <ghouston@arglist.com>
Date: 9 Apr 2002 20:28:25 +0100
The versions seemed a bit out of date, and the last policy I remember
is that the latest released versions are always used. Since it's easy
to find out what the versions are, it doesn't seem necessary to list
them in the file and saves the confusion when the released versions
differ from the file versions (is the file correct or did somebody
just forget to update it?)
for the most part the HACKING tools are stable; we've run accross
weirdness (recently and also going back, considering some of the
comments in the input files), but over time the tools live up to their
documentation.
to be precise and do minimal work, we need to record version numbers
only for problematic cases. this means every time there's a tool bug
discovered, HACKING needs to be updated, otherwise the default stance
(which we need to state explicitly) of "latest is greatest" holds.
we need to also remind people to check their tool distributor's policy
and practice.
btw, in fixing this bug we come to the process question of: how do bugs
fit into the TODO list? one obvious answer is "don't use TODO list, bug
fixing (for those deemed needing it) is best managed separately". this
is a not wholistic view however; bug fixing takes time which directly
affects what can be done on TODO. fundamentally, bug fixing is a (we
hope) non-repetitive action, something to do when the time is right.
(and if the particular fix is congruent w/ long term design, the fix
could be called one-shot.)
so i think it would be useful to consider ways to include bugs in the
TODO list. what does everyone think about this protocol:
- discuss bug
- someone proposes fix
- agree on fix
- add to TODO "NAME: FIX-ACTION" (or just "NAME" and use another level
to enumerate fix-action subtasks) under "Fix Bugs" (a new top-level)
- if a bug moves for whatever reason (for example under "Guile 1.6"), it
needs to be put under another "Fix Bugs" parent
? the basic characteristic here is that only bugs whose fixes are known
are added to TODO, and bug fix parent task is always easy to identify.
this helps keep TODO focus probably and definitely makes downstream
tools happy.
thi
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2002-04-10 6:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-09 17:12 Tool version in HACKING Marius Vollmer
2002-04-09 19:28 ` Gary Houston
2002-04-10 6:29 ` Thien-Thi Nguyen [this message]
2002-04-10 15:07 ` Rob Browning
2002-04-10 18:42 ` Thien-Thi Nguyen
2002-04-22 16:59 ` Thien-Thi Nguyen
[not found] ` <200204091928.MAA18084@onyx.he.net>
2002-04-15 13:59 ` Marius Vollmer
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=E16vBc8-0006ne-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).