> I have a slightly heretical point of view: I do not want my tickets in
> the same git repository as the code.
Hmm... and here I was, thinking this was the general consensus among
those people who have thought enough about it.
FWIW, BuGit has its own repository, and while it could easily be made to
use the same repository as some project's code, it's definitely not the main
use case.
I think some kind of integration between BTS and a code's VCS is
definitely worthwhile, but I don't think that "share the same
repository" is the best way to go about it (and even less so for "share
the same branch" as some systems do, IIUC).
> * A ticket represents an issue a user has, or a bug in the project, or
> a similar problem. The goal is to fix the problem.
Indeed, I started BuGit using the name "bug" but later changed it to
"issue" since there's no reason why this should be limited to tracking
bug reports.
> * All discussion is over email, to avoid making people have to sign up
> to a website. The emails are stored in a per-ticket Maildir. Later,
> a web UI can be added, which will add fake emails to the ticket, but
> that's optional for now.
BuGit currently has an email backend (so people who "follow" an issue
get email updates) but no email "frontend" (i.e. you can't create new
issues nor query nor manipulate issues over email the way Debbugs does).
An email front-end would be very welcome.
> * Having at least a read-only view of the system via a static
> rendering of the ticket system data is crucial. A more interactive
> one would be nice, of course.
Indeed, our experience with Debbugs is that it's important to have
a static read-only web representation for search-engines, coupled with
a dynamic (just based on CGI, IIUC) alternative.
BuGit currently is limited to a very rudimentary read-only rendering via CGI.
> * All ticketing system data is stored in git, and normal git
> operations are used for syncing. The data is stored in a way that
> makes merging unlikely to cause conflicts.
Right. That was the starting point for me (tho the choice of Git was
rather arbitrary).
Stefan
_______________________________________________
dist-bugs mailing list
[email protected]
http://kitenet.net/cgi-bin/mailman/listinfo/dist-bugs
