Hi, I really like Dovecot much so I can help with web frontend (have a several years of PHP experience and a few of Ruby on Rails).
But before the work begins I would vote for using Trac (http://trac.edgewall.org) :-) Here are also few reasons:
It is very easy to use and I think that it is actually much more helpful than annoying
Does not need almost anything - you already have Apache and Python and it uses SQLite as database which is really lightweight
And about the third reason - I came to Linux very late, about two years ago when HTTP already rules the world and Dovecot is the only mailing list in which I am subscribed. Both of my favorite distros (Gentoo and Ubuntu) use web forums for "support" and users love them. I can not say why but I also found everything web-based much friendlier to use than mailing list (but this is only my point of view of course).
Hmmmm, I forgot that that Trac is SVN based which can be a BIG problem
Láďa-----Original Message----- From: dovecot-bounces@dovecot.org [mailto:dovecot-bounces@dovecot.org] On Behalf Of Timo Sirainen Sent: Saturday, January 20, 2007 12:09 AM To: Dovecot Mailing List Subject: [Dovecot] Bug tracking system
There are three reasons why I haven't really bothered setting up a bug tracking system for Dovecot:
They're all kind of annoying to use.
They all require a lot of stuff like PHP, SQL server, etc. which I don't really want to put into dovecot.org.
Probably most importantly: If people start reporing bugs in there, I'm pretty much the only person who will ever read them and reply to them. Currently when people report bugs in here, it's quite useful to have other people read them too. They may already know the bug and say they've reported it, they may have an idea what's causing it, they may know a workaround, etc. All in all, moving things to BTS would most likely cause my life to be harder and it might be more difficult to get some bugs fixed.
A couple of days ago I started thinking about this and then I figured out a way to solve all of this nicely with a new and great Dovecot based bug tracking system. :) Just so I won't forget it, here's the plan:
Dovecot BTS
The preferred way to report bugs is to send them to dovecot-bugs@dovecot.org. The only thing it does is prefix the subject line with [BUG #nnn] and forward it to dovecot@dovecot.org.
Now everyone can reply to it just as it was a normal mailing list mail. As long the subject contains the "[BUG #nnn]" prefix, it's part of the bug.
Existing mailing list threads can also be turned into bugs by replying to the thread's root message with To: dovecot-bugs@dovecot.org. This again causes the new reply to contain [BUG #nnn] prefix.
Then comes the web part. There's no SQL database or anything, everything is stored in a mailbox in the IMAP server. The mailbox contains the whole dovecot@dovecot.org archive. Bug metadata such as priority, status, etc. is stored using IMAP ANNOTATE extension, which allows setting key=value pairs to messages. Unfortunately Dovecot doesn't yet support that extension.
Bugs' root messages contain the annotations for the whole bug thread. So to get a list of all bugs, the BTS issues an IMAP SEARCH ANNOTATE command to list all messages with some specific "bug=yes" type of annotation. For those messages then it can fetch the subject and whatever else metadata it wants.
Newly created bugs don't have annotations though. To fix that, the BTS also uses ANNOTATEMORE (or is it METADATA nowadays?) extension to keep "last seen message in BTS" state in the mailbox's annotations. It then issues a SEARCH SUBJECT "[bug #" command for the new messages and does THREAD command for them to see if they're the bug root, or if they were replies to another message which should be treated as the bug root.
When viewing a bug, the bug metadata comes from the annotations. Annotation history could also be kept, possibly as messages in another history mailbox. The messages for a bug can be viewed by issuing a THREAD (REFERENCES) command and showing all the mails that exist under the bug root.
So, any volunteers to implement the web part, if I implement the ANNOTATE extension? :) It would actually even be possible to implement multiple frontends. All I need to do is give you access (read-only, or read-write for some) to the bug tracking mailbox, and you can use whatever frontend you wish, even a non-web one!