guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tool version in HACKING


From: Thien-Thi Nguyen
Subject: Re: Tool version in HACKING
Date: Tue, 09 Apr 2002 23:29:52 -0700

   From: Gary Houston <address@hidden>
   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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]