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! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070120/f1315a46/attachment.bin>
On January 20, 2007 1:09:22 AM +0200 Timo Sirainen <tss at iki.fi> wrote:> 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:The major problem with that is you have to WRITE a web interface which will be different than bugzilla that everyone is used to. Tracking is also poor compared to bugzilla (or even gnats, which doesn't require php sql etc). If you ever want dovecot to become a project that would outlive your work on it, you should do bugzilla. -frank
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!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 19, 2007, at 6:09 PM, Timo Sirainen wrote:> 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.If you don't mind it being closed source, I would highly recommend Jira from Atlassian. First, it's an excellent bug tracking system and second, Atlassian (the company that makes Jira and it's wiki companion Confluence) provides free hosted services for some open source projects. I took them up on the offer for Mailman's wiki (see wiki.list.org) and am in the process of transitioning our bug tracking system from SourceForge to Jira (bugs.list.org). My main hang up is/was just extracting the data from SF and converting it for import into Jira -- but you won't have that problem because you're starting from scratch. ;) Oh, and while the /systems/ are closed, your data is not, so you can always extract it if you wanted to move again. If you want, contact me off-list and I'll see if I can dig up the Atlassian contact information. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRbFiAnEjvBPtnXfVAQLgoQQAjfQcflAjcR0bp+QFiL3Hy8M0dWsCWs8e Vt7G0D0H2FoDS20TIgFhxBfnxA2bjrfqFl78VOJW59H9TRm69WTM8xSJutVxekXn Sv8E8DNPkhdE7fl/WZhSHHi699E1hfLoPLjCuy1nLDHE7v7kaLJWXuF7+BJ6FT02 Wg7ue9OKefQ=9eMl -----END PGP SIGNATURE-----
On Sat, Jan 20, 2007 at 01:09:22AM +0200, Timo Sirainen wrote:> 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.Most trackers allow a mail gateway in at least one-way, e.g. to this list. The problem is that some people start answering on the mail and not on the tracker's interface, so part of the bug discussion gets lost. But there are even some systems that are completely two-way like rt (I think). bugzilla has extensions that allows two-way mail reporting, too.> 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:A BTS in dovecot sounds nice, but before diving into the implementation I'd check around and see what there is to simply use w/o developing. I think your specs could already be met by some existing tracking system properly tuned to your liking. If you need assistance for a "conventional" tracking system like bugzilla or trac's ticket system I can help. I can also help out with hosting if maintaining mysql or similar is not wanted on dovecot.org's main server. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20070120/4548e25e/attachment.bin>
Timo Sirainen wrote:> 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.And here is, really, the big motivation that makes a lot of sense. I've seen other BTS integrate with email (some even fairly successfully, I'm told), but starting from the PoV that it's a mailing list and extending it... great idea. And looking at some of the other replies, I suspect they missed this point. Keeping it on the list means people don't _need_ a special client to be involved.> 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!Count me in! This could be the excuse^H^H^H^H^H^H project I've been looking for to get some time in with PyGlade. Of course, someone handy with writing Thunderbird extensions could certainly make themselves popular here... -- Curtis Maloney cmaloney at cardgate.net
On Sat, 2007-01-20 at 01:09 +0200, Timo Sirainen wrote:> 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!I could write a MoinMoin wiki extension that allows you to interact with it within the wiki. I don't think I can do the whole thing on my own because such things invariably come with feature creep ;) johannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070216/8e827b5f/attachment.bin>
> > > I don't think I want an anonymous user to be able to create bugs. Maybe > > > what I'm after is an automatic user creation based on the given email > > > address, but the user won't be able to log in before verifying the > > > email. If a user already exists for the given email address, that bug > > > also belongs to that existing user even though no password was asked > > > (but it could mention that it was created anonymously and log the IP). > > > > But that's how most othe rregstration systems work too. All > > bugzilla/mailman etc. typically want is to verify the autheticity of > > the given email address. > > But why? If all you're doing is just adding a new bug, what's the point > of verifying the email address? It's just annoying to the user.Especially if someone like myself is already registered to the mailing list, I don't feel the need to go and register into a bugtracking system and have my email verified yet again.> I just made a simple mockup of what I'd like the "Enter new bug" page to > be like: http://dovecot.org/tmp/bug.htmlNice and simple is good. I'd include a couple of other fields to make it easy to get useful info, like dovecot version and OS. But I'd really prefer to just email reports in to the list.> The log in page would then allow logging in with email/password, or > allow "registering" the user by sending a new password to the email.Perhaps it can just be integrated with the maillist login page? -- Kenny Dail <kend at amigo.net>
Seemingly Similar Threads
- messages_count too large errors (1.0RC5)
- SUGGESTION: Use JIRA for Bug Reporting, Package Development and Project Management
- Bug reporting system inquiry plus a bug report related to sort
- JIRA anyone?
- AuthenticationFailedException: [IN-USE] Couldn't open INBOX: Permission denied