Re: Handling BUGS.

[Thien-Thi Nguyen]

   From: Marius Vollmer <address@hidden>
   Date: 23 Mar 2002 13:14:15 +0100

   What about calling it "workbook" instead of "devel"?

that's fine by me.

   I have a slightly uneasy feeling about splitting BUGS into multiple
   files.  CVS is not very good at moving or renaming files and we
   wouldn't have a centralized log any more.  I don't see any problems
   with just keeping all bugs in one file.

usually a bug, once interned into the system, should not move (and
should not be deleted).  its status and other attributes can change, of
course, but its relationship to the filesystem need not.  this property
is important; new bugs that are duplicates of, or related to, old bugs
need to be able to refer to old bugs (see bug 6, for example).  same
goes for regression tests.

generally, separating database format from presentation format allows
tuning presentation to everyone's individual taste.  i'm hoping Evan's
bugs renderer will have tasty customization hooks, etc.  a particularly
nice feature would be directory slices:

 cd /tmp
 render-bugs --dir-slice resolved .../workplace/bugs/

creates /tmp/resolved/{3,4,5} (symlinks to .../workplace/bugs/{3,4,5})
where 3,4,5 are determined to satisfy the pre-defined "resolved" filter.

then, you can do further render-bugs on /tmp/resolved/ (perhaps
recursing into /tmp/resolved/1.6/, etc).  when you're done, just rm -rf
/tmp/resolved/.

it would also be nice to accept a predicate for ad-hoc slicing:

 render-bugs --dir-slice-predicate ttn \
               '(equal? (bug-assq (quote reporter)) "ttn")'

bug-assq would need to be provided and other similar primitives.  mixing
pre-defined and ad-hoc reporting like this "allows the simple to be easy
and the complex to be possible" (to further promote a popular meme ;-).
for an example of this kind of reporting, see test-suite/guile-test.

thi