[Dovecot] Bug tracking system

[Láďa]

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:

1) It is very easy to use and I think that it is actually much more helpful
than annoying

2) 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 at dovecot.org [mailto:dovecot-bounces at 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:

1) They're all kind of annoying to use.

2) They all require a lot of stuff like PHP, SQL server, etc. which I
don't really want to put into dovecot.org.

3) 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 at dovecot.org. The only thing it does is prefix the subject
line with [BUG #nnn] and forward it to dovecot at 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 at 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 at 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!