Re: collision problem

[Graham Percival]

On 8/28/08, Mats Bengtsson <address@hidden> wrote:
>
> James E. Bailey wrote:
>> Speaking of which, how difficult would it be to collect a "known
>> issues" list? Something akin to the LSR, but for known issues for
>> which there are solutions. It would help tons when troubleshooting why
>> a particular output isn't what's expected.
>
> Isn't the intention to
> - Fix the issues in the implementation
> - If that's not possible (or not yet done) document it as a Known issue
> in the most relevant subsection of the manual.
>
> Of course, we could collect a list of all "Known issues" from the manual
> at one place, but I'm not sure how helpful it would be.

It's not quite that simple.  There are a few types of issues:
1. workaround exists
2. broken but relatively easy to fix
3. broken but not easy to fix
4. not working, but never planned to work due to fundamental design
5. not working in the way you want it to, but you can get the desired
output in another way.

... there's probably a few more, as well.

Currently, #1, #3, and #4 are /theoretically/ covered by @knownissues.
 The plan in GDP /was/ to make this non-theoretical, but the resources
just weren't there so I dropped this idea.

#2 is not supposed to be in @knownissues at all.  #5 /might/ be
included, but in general I think we don't.  So currently an
experienced user would look both the NR and the tracker to look for
issues or workarounds... not to mention searching the mailist archives
as well.  I know of at least two issues where the solution is in the
mailist but not the tracker or the manual.

Again, it's a question of resources.  If I had an infinite amount of
advanced user helpers who would do my bidding (but for some reason
refused to learn scheme and do bug fixes), then sure, I'd recommend
creating such a system.  Since we don't, I won't.  Too much work, not
enough benefit (compared to other benefits from a similar amount of
work).

Cheers,
- Graham