[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Handling BUGS.
From: |
Thien-Thi Nguyen |
Subject: |
Re: Handling BUGS. |
Date: |
Sat, 23 Mar 2002 13:43:29 -0800 |
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
- Re: Handling BUGS., (continued)
- Re: Handling BUGS., Evan Prodromou, 2002/03/22
- Re: Handling BUGS., Thien-Thi Nguyen, 2002/03/22
- Re: Handling BUGS., Evan Prodromou, 2002/03/22
- Re: Handling BUGS., Thien-Thi Nguyen, 2002/03/22
- Re: Handling BUGS., Rob Browning, 2002/03/22
- Re: Handling BUGS., Thien-Thi Nguyen, 2002/03/22
- Re: Handling BUGS., Marius Vollmer, 2002/03/23
- Re: Handling BUGS., Rob Browning, 2002/03/23
- Re: Handling BUGS., Rob Browning, 2002/03/23
- Re: Handling BUGS., Marius Vollmer, 2002/03/24
- Re: Handling BUGS.,
Thien-Thi Nguyen <=
- Re: Handling BUGS., Marius Vollmer, 2002/03/24
- Re: Handling BUGS., Thien-Thi Nguyen, 2002/03/24
- Re: Handling BUGS., Marius Vollmer, 2002/03/24
- Re: Handling BUGS., Rob Browning, 2002/03/24
- Re: Handling BUGS., Marius Vollmer, 2002/03/24
- Re: Handling BUGS., Rob Browning, 2002/03/24
- Re: Handling BUGS., Thien-Thi Nguyen, 2002/03/25
- Re: Handling BUGS., Marius Vollmer, 2002/03/25
- Re: Handling BUGS., Thien-Thi Nguyen, 2002/03/25
- Re: Handling BUGS., Marius Vollmer, 2002/03/25