Maybe I'm crazy, but I'm starting a new project of my own, and I thought,
"Hey, I don't want to spend the effort to set up Bugzilla, I don't have the
money to spend on IssueZilla (as nice as it looks), and I don't have a Tomcat
server available to run Scarab. Why not put my issues in the obvious place,
with the rest of my source?"
Stop reading this right now if you think I'm insane. Mostly I'm just thinking
aloud here, but I'm also soliciting comments on (1) why this is or could be
doomed to fail from the start, or (2) um, just comments. If a significant
number of people don't think I'm insane, then I might just start developing
this as its own project, for use outside my own project.
What I'm envisioning consists of some scripts and maybe a web interface, and
an addition to the somewhat standard subversion tree, called "issue/" (note
that out of my own convention, I don't pluralize the directory names, but
adapt as you will; names would be configurable):
repos/
trunk/
branch/
issue/
[issue-names]/
release/
[release-names]/
tag/
milestone/
release/
issue/
assigned/
[commiters'-usernames]/
[issue-names]/
new/
[issue-names]/
resolved/
[issue-names]/
Each issue gets its own directory within either new/, assigned/[username]/, or
resolved/, and that directory gets "svn mv"ed around as its status changes.
If svn supported symbolic links right now, I'd want to also have a directory
called "all/", where all the "real" issue directories would be stored, and
then the ones in assigned/, new/, and resolved/ would just be links. The
issues' names would likely be prefixed by (or consist only of) a number, just
like each issue in other trackers gets its own unique ID. Naming conventions
would ensure that two people don't commit two issues with the same number at
the same time, since that would cause a conflict.
Within each issue directory, the original issue is stored as a file called
"issue". This is a plain text file, and it functions similar to the way in
which, say, Debian's bug tracking works over email. It consists of headers
in "Header-Name: Contents" form, followed by the description of the issue.
The headers are obvious, like "Summary:", "Author:", "Date:", "Platform:",
"Component:", etc. Also contained in this file are headers like "Status:",
which are modified when necessary.
Each new comment to the issue gets stored as "comment-XXX", where people can
post comments with similar headers.
And of course people could post attachments as regular files, maybe in an
"attachments/" subdirectory.
Do you think I'm crazy yet? Obviously this is heavily reliant on people
following some seemingly arbitrary naming conventions. If I develop this
further, most of that development will go towards making a set of
cross-platform scripts (Python?) to do the dirty work of creating the files
and ensuring validity, possibly as a post-commit script to do the management.
Alternatively, if it's ever possible to run PHP scripts straight out of a
mod_dav_svn repository, then it could get really interesting... :) I could
write a web interface that itself is part of the repository, maybe treated
like a vendor branch.
As you can see, my goal is to have all my issues, tools, source, ...everything
all self-contained in a single repository. Subversion, with its nice
directory support, lends itself to this goal. Also, it would allow easy
editing of issues with *any* editor (not just a web browser, which I think is
one reason why existing issue trackers don't appeal to me) with full history.
Immediate advantages:
* Text based: edit/create with any editor, search with "grep -r"
* Automatically organizing: the most common reporting can be done with "svn
ls" (see who is working on what, check up on new issues, see what has been
resolved).
* Automatically benefits from commit-email.pl
* Full history tracking: Subversion records the date and author of all
additions, and you can even edit existing issues to correct typos.
Issues with my issues:
* What would be expected of log messages to issue commits? Writing a log
message in addition to writing an issue description would get tedious.
* Before a web or other interface is created, creating new issues will be
especially tedious. A template system could alleviate some of this.
* [your comments here]
Todo before it's really viable:
* Use PHP, Perl, or Python with SWIG svn bindings to write a web interface.
* Along those lines, it should be possible to run PHP/CGI in Apache straight
from a repository (maybe it is already, I haven't tried).
* Figure out a way to easily and efficiently index all of the issues.
* Subversion needs to support symbolic links. This would simplify
organizational issues, and also would enable logical dependency tracking by
creating links directly from one issue to another (in a dependency/
subdirectory, maybe). Modules (svn:externals) could substitute in the mean
time, but modifying svn:externals would be tedious and unmaintainable.
Does everyone still think I'm crazy? I guess it doesn't matter, since anyone
reading this is obviously crazy and has too much free time. Let me know what
you think; is such a project worth further thought? Was this incredibly long
email worth your time? :)
DISCLAIMER: Of course I would never want to distract from Collabnet's
SourceCast/IssueZilla, from which I understand much of the support for
Subversion comes, or from the other issue trackers hosted by Tigris.org :)
--
Peter Davis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 1 10:12:51 2002