Based on my previous comment, I realized it seems that bug-fixes will not look like they do today in a Naiad context. Due to the non-use of files in naiad, it seems that an external issue tracker may not even be an option! Therefore, we should consider this in the design.
How would issue-tracking work in a system like naiad? First, we should define what kind of issues we are interested in: 1. Bug reports (manual and/or automatic): an end-user finds a problem, fills out a form with relevant info, and may or may not follow-up to it. Walkbacks could make this semi-automatic. There is already a button somewhere in squeak to email a bug report to the mailing list, but I don't remember where. 2. Code Requests: A developer encounters code exhibiting ugliness, non-existence, or general lameness, and submits an issue that said code should be cleaned up. 3. Meta-issues: Issues to keep track of other issues, such as Mother-of-X issues, issues to be included in a release, relationships/dependencies between issues, duplicate reports, etc.
One way this could work is that an issue would be an item/module in the history database, which would hold comments somehow. As the issue marches toward completion, it would sprout dependencies on new code modules which would be loaded when someone syncs with the issue, the idea being that these dependencies resolve the issue when loaded.
If the issue is not-trivial, multiple-passes at a fix would be made. This would use whatever mechanism naiad already has in place to keep track of old versions of stuff.
I don't know if naiad already supports relationships among entities, but I suspect it does. Issues could: - DEPEND on code modules, other issues, or anything - DUPLICATE other issues, meaning that all comments/submissions on one issue should be redirected to another, probably just by convention - RELATE to other entities. A way to mark relationships for the benefit of future readers. No special meaning in code
It is not clear to me, being unfamiliar with naiad, whether this scheme is necessary, overkill, or not already present. It is also not clear whether this would be better-handled by something already present but not naiad-aware, like Mantis or Gjallar. I bring it up because all the issue trackers I have used expect objects/patches to be files, which does not match with naiad at all, and so are of lesser, if any, utility to naiad users.