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.
--
Matthew Fulmer --
http://mtfulmer.wordpress.com/_______________________________________________
Spoon mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon
Locked
