Fixed bugs seem uninteresting. Several things failed on my
car, for instance, that were fixed. There is rarely the need
to revisit failures, except possibly in regression tests, like
brakes :-)
Except for release notes, why would anyone want to know about
fixed bugs? At most someone running an old
> 6) Bugs are part of the source tree
To me, it would be sufficient, if fixed bug come with a commit message
that describes the bug that is fixed and the source code contains a test
that corresponds to the bug.
I don't necessarily need open bugs in the source tree. They could live
in the same rep
The bug list brings out several aspects of literate programming
that are not obvious at first glance but make a qualitative
difference in maintaining code. Previously people have turned
to IDEs to provide these features. IDEs are just more code to
maintain, often with very task-specific hacks that
Bug tracker in book form? I don't think that's a good idea.
On Fri, Aug 5, 2016 at 4:17 AM, Tim Daly wrote:
> In the spirit of the game I'm moving the buglist to be a full
> literate volume, published like all the others. This will allow
> automation, extraction and testing of various bugs
> duri
> Bug tracker in book form? I don't think that's a good idea.
Because?
I can already see benefits.
Organizing bugs in book form makes it easier to search. The
chapter (e.g. hyperdoc), section (e.g. content, typo, wishlist),
and cross-reference (e.g. to the other books) make it easier
to find alr
