[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!
On January 20, 2007 1:09:22 AM +0200 Timo Sirainen <tss@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
On Fri, 2007-01-19 at 15:44 -0800, Frank Cusack wrote:
On January 20, 2007 1:09:22 AM +0200 Timo Sirainen <tss@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.
Last time I asked about BTS here, people seemed to say "use anything but bugzilla". So I don't think that's going to be such a big problem..
However I don't see why Dovecot BTS's tracking would have to be any worse than other BTSes. It would have a familiar web interface that would work just the same way as the others. But the main thing is that it would also allow people in mailing list to "use" the BTS, which they wouldn't otherwise do if it were a separate Bugzilla or similar.
On January 20, 2007 2:01:01 AM +0200 Timo Sirainen <tss@iki.fi> wrote:
However I don't see why Dovecot BTS's tracking would have to be any worse than other BTSes. It would have a familiar web interface that would work just the same way as the others. But the main thing is that it would also allow people in mailing list to "use" the BTS, which they wouldn't otherwise do if it were a separate Bugzilla or similar.
That's true, bugzilla forcing you to the web does suck, but you can just use gnats which has an email interface too.
I just don't see why you'd want to reinvent this wheel.
-frank
Timo Sirainen writes:
Last time I asked about BTS here, people seemed to say "use anything but bugzilla". So I don't think that's going to be such a big problem..
Catching up with the archives.. Don't know if you solved this already.. but I agree with NOT using Bugzilla.
However I don't see why Dovecot BTS's tracking would have to be any worse than other BTSes.
Have you ever checked out http://www.mantisbt.org?
Seems very user friendly. Don't know about the installation though.
On Fri, 2007-02-09 at 12:06 -0500, Francisco Reyes wrote:
Have you ever checked out http://www.mantisbt.org?
I much prefer bugzilla over mantis. Mantis is almost as bad as the SF.net tracker in that it always sends out junk via email, can't be used via email, and needs a username/password to log in. Count me out.
johannes
On Friday February 16, 2007 at 07:20:17 (AM) Johannes Berg wrote:
I much prefer bugzilla over mantis. Mantis is almost as bad as the SF.net tracker in that it always sends out junk via email, can't be used via email, and needs a username/password to log in. Count me out.
Forcing the reporter to be a registered user is a good thing. I worked on a project for awhile where it seemed that every jerk would submit some sort of report. The reports were usually incomplete and since there were no accounts linked to the reports, there was no way to contact the OP. In my opinion, if the bug-reporter cannot take the time to register, then they can just keep their bug-reports to themselves.
Just my 2¢.
-- Gerard
On Fri, Feb 16, 2007 at 10:02:25AM -0500, Gerard wrote:
On Friday February 16, 2007 at 07:20:17 (AM) Johannes Berg wrote:
I much prefer bugzilla over mantis. Mantis is almost as bad as the SF.net tracker in that it always sends out junk via email, can't be used via email, and needs a username/password to log in. Count me out.
Forcing the reporter to be a registered user is a good thing. I worked on a project for awhile where it seemed that every jerk would submit some sort of report. The reports were usually incomplete and since there were no accounts linked to the reports, there was no way to contact the OP. In my opinion, if the bug-reporter cannot take the time to register, then they can just keep their bug-reports to themselves.
Just my 2??.
FWIW I'm less inclined to report a problem if I have to register somewhere or join something to do so. I suppose that might be jerky of me, I dunno. One can always ignore reports that can't be understood or followed up on; but conversely, one can't act on reports that one never receives.
My 2c :)
mm
On Friday February 16, 2007 at 10:46:16 (AM) Mark E. Mallett wrote:
FWIW I'm less inclined to report a problem if I have to register somewhere or join something to do so. I suppose that might be jerky of me, I dunno. One can always ignore reports that can't be understood or followed up on; but conversely, one can't act on reports that one never receives.
I honestly have no idea why some individuals desire such an extreme level of anonymity. The bug-tracker can be configured to keep the reporters information hidden from other bug-reporters.
In any case, a user who declines to supply his/her contact information obviously has no expectations of being contacted for further information regarding their complaint and therefore should not expect their alleged bug to be worked on in a speedy if eventual manner.
-- Gerard
"It is not the OS's job to stop you from shooting your foot. If you so choose to do so, then it is OS's job to deliver Mr. Bullet to Mr Foot in the most efficient way it knows."
On Fri, 2007-02-16 at 11:20 -0500, Gerard wrote:
On Friday February 16, 2007 at 10:46:16 (AM) Mark E. Mallett wrote:
FWIW I'm less inclined to report a problem if I have to register somewhere or join something to do so. I suppose that might be jerky of me, I dunno. One can always ignore reports that can't be understood or followed up on; but conversely, one can't act on reports that one never receives.
I honestly have no idea why some individuals desire such an extreme level of anonymity. The bug-tracker can be configured to keep the reporters information hidden from other bug-reporters.
I don't think the problem is anonymity, but the effort required to register. The BTS could require that you give an email address, but it shouldn't require you to create yet another username/password pair that you have to remember.
I have a few times not bothered to report some pretty clear bugs just because I didn't see any easy enough way to do that. Of course that meant that the bug didn't get fixed, but since I was only testing their software (or auditing their sources) I didn't really care about that. For Dovecot I do want bug reports from people like me.
On Fri, Feb 16, 2007 at 07:00:00PM +0200, Timo Sirainen wrote:
On Fri, 2007-02-16 at 11:20 -0500, Gerard wrote:
On Friday February 16, 2007 at 10:46:16 (AM) Mark E. Mallett wrote:
FWIW I'm less inclined to report a problem if I have to register somewhere or join something to do so. I suppose that might be jerky of me, I dunno. One can always ignore reports that can't be understood or followed up on; but conversely, one can't act on reports that one never receives.
I honestly have no idea why some individuals desire such an extreme level of anonymity. The bug-tracker can be configured to keep the reporters information hidden from other bug-reporters.
I don't think the problem is anonymity, but the effort required to register. The BTS could require that you give an email address, but it shouldn't require you to create yet another username/password pair that you have to remember.
For bugzilla the remembering is in my browser. :)
I have a few times not bothered to report some pretty clear bugs just because I didn't see any easy enough way to do that. Of course that meant that the bug didn't get fixed, but since I was only testing their software (or auditing their sources) I didn't really care about that. For Dovecot I do want bug reports from people like me.
This is for example trac's model. But it has shown to be a failure in that once it became popular enough for spammers to care, it is being abused to beyond recognition. And nowadays trac admins either dump the ticketing part or restrict to registred users (which are non-trivial to register under trac), or use captchas etc.
But you can run bugzilla and friends anonymously, if you like. You create an account for that anonymous user and display the info for using it on the "new bug" page.
Axel.Thimm at ATrpms.net
On Fri, 2007-02-16 at 21:55 +0100, Axel Thimm wrote:
I have a few times not bothered to report some pretty clear bugs just because I didn't see any easy enough way to do that. Of course that meant that the bug didn't get fixed, but since I was only testing their software (or auditing their sources) I didn't really care about that. For Dovecot I do want bug reports from people like me.
This is for example trac's model. But it has shown to be a failure in that once it became popular enough for spammers to care, it is being abused to beyond recognition. And nowadays trac admins either dump the ticketing part or restrict to registred users (which are non-trivial to register under trac), or use captchas etc.
I was just thinking that I'd want to change Dovecot wiki to allow anonymous edits again, but to avoid spam there could be some simple question in the page that needs to be answered. For example "Type Dovecot in the field below". As long as spambots don't specifically try to spam wiki.dovecot.org (which is unlikely), it's safe.
The same thing could be done with bugs.dovecot.org. And the bugs.dovecot.org could anyway have completely non-bugzilla-like bug reporting interface so that spambots don't even recognize it.
But you can run bugzilla and friends anonymously, if you like. You create an account for that anonymous user and display the info for using it on the "new bug" page.
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).
On Fri, Feb 16, 2007 at 11:30:37PM +0200, Timo Sirainen wrote:
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. And both mentioned projects use the email address as the account name (not that mailman has anything to do with bugs/tickets, I'm just mentioning it for the registration procedure).
Axel.Thimm at ATrpms.net
On Fri, 2007-02-16 at 22:34 +0100, Axel Thimm wrote:
On Fri, Feb 16, 2007 at 11:30:37PM +0200, Timo Sirainen wrote:
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.
So sure you can use someone else's email address there, but why would anyone do that? Even if someone did, all it means is that the real owner complains about it and the address gets removed from the BTS.
Another possibly good reason for verification is if you typoed your email, but if the BTS by default sends you an email reply you'll notice the typo if you don't receive the email. Then the address can be changed by a BTS admin. And I expect this to be a rare problem also.
I just made a simple mockup of what I'd like the "Enter new bug" page to be like: http://dovecot.org/tmp/bug.html
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.
On Fri, Feb 16, 2007 at 11:49:10PM +0200, Timo Sirainen wrote:
On Fri, 2007-02-16 at 22:34 +0100, Axel Thimm wrote:
On Fri, Feb 16, 2007 at 11:30:37PM +0200, Timo Sirainen wrote:
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.
Don't you want feedback? Therefore an email address should be mandatory. And if you don't verify it then you either have bogus emails or Joe jobs.
You can't have the whole pie and the dog fed (old greek saying ;)
Axel.Thimm at ATrpms.net
On Fri, 2007-02-16 at 22:53 +0100, Axel Thimm wrote:
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.
Don't you want feedback? Therefore an email address should be mandatory. And if you don't verify it then you either have bogus emails or Joe jobs.
You can't have the whole pie and the dog fed (old greek saying ;)
If someone bothers to report a bug, I doubt he/she gives a bogus email address. And if he does, the alternative is probably that the bug wouldn't be reported at all. Which I think is worse than getting bogus bug reports.
And to make it even less likely to get bogus addresses, I added "Show the address only to admins" to http://dovecot.org/tmp/bug.html
On Fri, Feb 16, 2007 at 11:20:49AM -0500, Gerard wrote:
On Friday February 16, 2007 at 10:46:16 (AM) Mark E. Mallett wrote:
FWIW I'm less inclined to report a problem if I have to register somewhere or join something to do so. I suppose that might be jerky of me, I dunno. One can always ignore reports that can't be understood or followed up on; but conversely, one can't act on reports that one never receives.
I honestly have no idea why some individuals desire such an extreme level of anonymity. The bug-tracker can be configured to keep the reporters information hidden from other bug-reporters.
Non-sequitor. Do I seem concerned about my anonymity? I hadn't even thought about that. Still, maybe that is a concern for some, I dunno.
I think one has to be skeptical of statements like "if you can't be bothered to do <x> then you shouldn't expect to do <y>" -- at least enough to examine whether the connection between x and y is something you need to take into account. Similarly of "I don't see why some people are concerned about <z>, because I'm not" enough to examine whether the concern z can be accomodated even if you don't personally have it or believe in it.
Really, in the area of bug reports it's up to the person or entity that wants to receive and act on reports. People are different. Some may want to require registration, and so be it. But again, my opinion is that it may turn some people away. Some may see that as a benefit, and sometimes it may truly be one. I simply gave my perspective.
-mm-
Forcing the reporter to be a registered user is a good thing. I worked on a project for awhile where it seemed that every jerk would submit some sort of report. The reports were usually incomplete and since there were no accounts linked to the reports, there was no way to contact the OP. In my opinion, if the bug-reporter cannot take the time to register, then they can just keep their bug-reports to themselves.
Well - other than the occasional post that fails to provide minimal details (system/platform/version, dovecot version, etc), this hasn't been a real problem yet...
*If* it did actually become a problem, I'd prefer a two-tiered system...
For initial bug reports, just let 'any jerk' report the bug.
Then, once the bug has been verified, *and* if Timo doesn't find/fix it immediately (which he often does) or know what it would take to fix it and cannot do it quickly or without breaking something major, then someone (Timo, or maybe some other volunteers who would have access to the back-end bug reporter) could add it as a 'Verified' bug, which would then have its own thread for those experiencing the bug to try to help Timo figure out what is causing it.
The thing I like most about the way Timo wants to do this is he wants to make it both very easy for people to submit bug reports, and for people to respond/follow-up to them.
I'd also like to see some kind of listserv command that could be sent to get a list of currently open bugs and their status...
I'd also like to have a gorgeous live-in maid who served me breakfast in bed every morning... oh, sorry, was I dreaming again?
--
Best regards,
Charles
On Fri, 2007-02-16 at 10:02 -0500, Gerard wrote:
Forcing the reporter to be a registered user is a good thing.
No, it's absolutely not.
I worked on a project for awhile where it seemed that every jerk would submit some sort of report. The reports were usually incomplete and since there were no accounts linked to the reports, there was no way to contact the OP. In my opinion, if the bug-reporter cannot take the time to register, then they can just keep their bug-reports to themselves.
You're saying "not anonymous reporter" == "registered user" which is not true at all. I'm fine with doing stuff via email, and I sometimes even sign up for bugzilla accounts, but mantis sometimes doesn't even let you *view* things without logging in via some strange guest account thingie. It's convoluted.
johannes
Johannes Berg wrote:
On Fri, 2007-02-09 at 12:06 -0500, Francisco Reyes wrote:
Have you ever checked out http://www.mantisbt.org?
I much prefer bugzilla over mantis. Mantis is almost as bad as the SF.net tracker in that it always sends out junk via email, can't be used via email, and needs a username/password to log in. Count me out.
johannes
there seems to be a view that it's better to write something from scratch. i'm not convinced that this actually aids dovecot directly in any way.
perhaps something like http://trac.edgewall.org/ would be a solution? integrated moinmoin wiki (& a migration tool), optional source browser (svn only) etc etc.
the bug tracker is the functionality needed, shouldn't be necessary to start from scratch.
a+ scorch
On Sat, 2007-01-20 at 02:01 +0200, Timo Sirainen wrote:
On Fri, 2007-01-19 at 15:44 -0800, Frank Cusack wrote:
On January 20, 2007 1:09:22 AM +0200 Timo Sirainen <tss@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.
Last time I asked about BTS here, people seemed to say "use anything but bugzilla". So I don't think that's going to be such a big problem..
However I don't see why Dovecot BTS's tracking would have to be any worse than other BTSes. It would have a familiar web interface that would work just the same way as the others. But the main thing is that it would also allow people in mailing list to "use" the BTS, which they wouldn't otherwise do if it were a separate Bugzilla or similar.
I may jump in a little bit late, but I didn't notice this thread until now.
What you say is not really correct. The usual way to have bugtrackers interact with a larger development/user community is to have the BTS automagically do this:
#1: post all incoming bugs (entered via a [web] interface) to a mailing list, such as dovecot-bugs
#2: post all follow-ups entered via a [web] interface to the same mailing list
#3: allow email based replies based on the subject line that go back directly into the bugtracker
That way, you would not be the only one that reads the emails and it also allows responding to bugs via regular emails.
All this can be easily setup for bugzilla and mantis (the only ones that I personally have dealt with to a greater extent so far).
If help is needed to get such a configuration working (also including hosting of such a solution), I personally (and the company I work for) would be happy to help out.
-- Udo Rader
bestsolution.at EDV Systemhaus GmbH http://www.bestsolution.at
On Fri, 2007-02-09 at 18:31 +0100, Udo Rader wrote:
#1: post all incoming bugs (entered via a [web] interface) to a mailing list, such as dovecot-bugs
Would be nice also to translate existing mails in mailing list into bug reports, but I guess it's not that horrible if it has to be copy&pasted and another mail about that bug then appears.
Also I'd rather not require users to register into the BTS at all to add new bugs. Just writing the bug subject, description and giving an email address should be enough.
#3: allow email based replies based on the subject line that go back directly into the bugtracker
Also from people not registered to the bug tracker? What about creating/preserving Message-ID / References headers so that the comments in one bug also show up as a single thread in the mailing list?
All this can be easily setup for bugzilla and mantis (the only ones that I personally have dealt with to a greater extent so far).
If help is needed to get such a configuration working (also including hosting of such a solution), I personally (and the company I work for) would be happy to help out.
If the above two things could be made to work, I guess we could finally have a bug tracker. :)
Timo Sirainen wrote:
Also I'd rather not require users to register into the BTS at all to add new bugs. Just writing the bug subject, description and giving an email address should be enough.
#3: allow email based replies based on the subject line that go back directly into the bugtracker
Something like the Debian BTS perhaps? I don't know what sw they use but it's quite good (from my point of view).
Dick
Dick Middleton:
#3: allow email based replies based on the subject line that go back directly into the bugtracker
Something like the Debian BTS perhaps? I don't know what sw they use but it's quite good (from my point of view).
I haven't seen it outside of the Debian project, but it is packaged (at least for Debian) under the name debbugs: http://packages.debian.org/debbugs
J.
As a child I pulled the legs from a spider. [Agree] [Disagree] <http://www.slowlydownward.com/NODATA/data_enter2.html>
On Thu, 2007-02-15 at 19:25 +0200, Timo Sirainen wrote:
On Fri, 2007-02-09 at 18:31 +0100, Udo Rader wrote:
#1: post all incoming bugs (entered via a [web] interface) to a mailing list, such as dovecot-bugs
Would be nice also to translate existing mails in mailing list into bug reports, but I guess it's not that horrible if it has to be copy&pasted and another mail about that bug then appears.
Yes, that is certainly not difficult.
Also I'd rather not require users to register into the BTS at all to add new bugs. Just writing the bug subject, description and giving an email address should be enough.
Yes, that is possible as well. There are two options for this:
#1 Users remain unidentified and the bug is posted as a global user
#2 Users are looked up based upon their email address. If an unknown email address enters a bug report or adds note to an existing bug report, it is automatically added as a BTS user.
The latter has the big advantage that users can identify their own bugreports/notes much easier later on.
Well, the disadvantage of this however is that it requires some countermeasures to prevent spammers from using it as their way to make us all happy with their lottery winnings, "enlargment" stuff and such :-)
#3: allow email based replies based on the subject line that go back directly into the bugtracker
Also from people not registered to the bug tracker? What about creating/preserving Message-ID / References headers so that the comments in one bug also show up as a single thread in the mailing list?
Yes, that is #2 from above. And about the headers ... the bugzilla email interface support this, mantis however (which I would favour for various reasons) does not support this out of the box AFAIK, but it is OSS, so it should not be too difficult to patch it.
Threading however is always possible based upon the subject of the autogenerated mails coming from the BTS.
All this can be easily setup for bugzilla and mantis (the only ones that I personally have dealt with to a greater extent so far).
If help is needed to get such a configuration working (also including hosting of such a solution), I personally (and the company I work for) would be happy to help out.
If the above two things could be made to work, I guess we could finally have a bug tracker. :)
Sure, if I can provide anything to get things working, just let me know.
-- Udo Rader
bestsolution.at EDV Systemhaus GmbH http://www.bestsolution.at
Took a while to reply because I haven't wanted to spend time on thinking about this.
On Thu, 2007-02-15 at 22:23 +0100, Udo Rader wrote:
Also I'd rather not require users to register into the BTS at all to add new bugs. Just writing the bug subject, description and giving an email address should be enough.
Yes, that is possible as well. There are two options for this:
#1 Users remain unidentified and the bug is posted as a global user
#2 Users are looked up based upon their email address. If an unknown email address enters a bug report or adds note to an existing bug report, it is automatically added as a BTS user.
The latter has the big advantage that users can identify their own bugreports/notes much easier later on.
Yep. 2) is good.
Well, the disadvantage of this however is that it requires some countermeasures to prevent spammers from using it as their way to make us all happy with their lottery winnings, "enlargment" stuff and such :-)
Would be nice to get it integrated with this mailing list's subscriptions list. Subscribers can send bugs immediately, non-subscribers' bugs get moderated. Just like they are now. And bugs sent via web page wouldn't require moderation but a really simple captcha (like wiki.dovecot.org has now), which should prevent all spambots.
Maybe the Mailman's subscriptions list could be pushed to the bugreporting system whenever it changes.
#3: allow email based replies based on the subject line that go back directly into the bugtracker
Also from people not registered to the bug tracker? What about creating/preserving Message-ID / References headers so that the comments in one bug also show up as a single thread in the mailing list?
Yes, that is #2 from above. And about the headers ... the bugzilla email interface support this, mantis however (which I would favour for various reasons) does not support this out of the box AFAIK, but it is OSS, so it should not be too difficult to patch it.
Threading however is always possible based upon the subject of the autogenerated mails coming from the BTS.
I just always hate it when people break the threads in this mailing list. Evolution uses only References/In-Reply-To headers to track them.
All this can be easily setup for bugzilla and mantis (the only ones that I personally have dealt with to a greater extent so far).
If help is needed to get such a configuration working (also including hosting of such a solution), I personally (and the company I work for) would be happy to help out.
If the above two things could be made to work, I guess we could finally have a bug tracker. :)
Sure, if I can provide anything to get things working, just let me know.
I'd at least like to try this. It would be nice to get a working bug tracker before v1.0 release. But I still have doubts about how annoying it would be to actually use, and how much time it would require to change everything to work just the way I want. I've already spend too much time changing MoinMoin, and Mailman's reply-to-list changes were kind of a waste of time too :)
As for Bugzilla vs. Mantis, I'm not that big of a fan of Bugzilla, but I pretty much hate how Mantis looks like at least in http://www.futureware.biz/mantisdemo/. It's way too confusing. Bugzilla's default look is OK, although in either case I'd want the "report new bug" page to look something like http://dovecot.org/tmp/bug.html
Den 22-03-2007 03:35, Timo Sirainen skrev:
Took a while to reply because I haven't wanted to spend time on thinking about this.
On Thu, 2007-02-15 at 22:23 +0100, Udo Rader wrote:
Also I'd rather not require users to register into the BTS at all to add new bugs. Just writing the bug subject, description and giving an email address should be enough. Yes, that is possible as well. There are two options for this:
#1 Users remain unidentified and the bug is posted as a global user
#2 Users are looked up based upon their email address. If an unknown email address enters a bug report or adds note to an existing bug report, it is automatically added as a BTS user.
The latter has the big advantage that users can identify their own bugreports/notes much easier later on.
Yep. 2) is good.
Well, the disadvantage of this however is that it requires some countermeasures to prevent spammers from using it as their way to make us all happy with their lottery winnings, "enlargment" stuff and such :-)
Would be nice to get it integrated with this mailing list's subscriptions list. Subscribers can send bugs immediately, non-subscribers' bugs get moderated. Just like they are now. And bugs sent via web page wouldn't require moderation but a really simple captcha (like wiki.dovecot.org has now), which should prevent all spambots.
Maybe the Mailman's subscriptions list could be pushed to the bugreporting system whenever it changes.
#3: allow email based replies based on the subject line that go back directly into the bugtracker Also from people not registered to the bug tracker? What about creating/preserving Message-ID / References headers so that the comments in one bug also show up as a single thread in the mailing list? Yes, that is #2 from above. And about the headers ... the bugzilla email interface support this, mantis however (which I would favour for various reasons) does not support this out of the box AFAIK, but it is OSS, so it should not be too difficult to patch it.
Threading however is always possible based upon the subject of the autogenerated mails coming from the BTS.
I just always hate it when people break the threads in this mailing list. Evolution uses only References/In-Reply-To headers to track them.
All this can be easily setup for bugzilla and mantis (the only ones that I personally have dealt with to a greater extent so far).
If help is needed to get such a configuration working (also including hosting of such a solution), I personally (and the company I work for) would be happy to help out. If the above two things could be made to work, I guess we could finally have a bug tracker. :) Sure, if I can provide anything to get things working, just let me know.
I'd at least like to try this. It would be nice to get a working bug tracker before v1.0 release. But I still have doubts about how annoying it would be to actually use, and how much time it would require to change everything to work just the way I want. I've already spend too much time changing MoinMoin, and Mailman's reply-to-list changes were kind of a waste of time too :)
As for Bugzilla vs. Mantis, I'm not that big of a fan of Bugzilla, but I pretty much hate how Mantis looks like at least in http://www.futureware.biz/mantisdemo/. It's way too confusing. Bugzilla's default look is OK, although in either case I'd want the "report new bug" page to look something like http://dovecot.org/tmp/bug.html
How about using trac[1]? I can assist setting up and maintain it if you'd like. (It's also possible to use trac without svn if you do not want to use subversion.)
- I think it should be fairly easy to make mailman update the trac permission system.
- As for captchas there is a version of the trac SpamFilter[2] that implements this.
- Trac utilises the References and In-Reply-To headers.
What do you think? I can set up a demo during the weekend if it sounds interesting.
References: [1] http://trac.edgewall.org/ [2] http://trac.edgewall.org/wiki/SpamFilter
-- Vennlig hilsen
Christian Skarby Interhost ANS
On Thu, 2007-03-22 at 10:33 +0100, Christian Skarby wrote:
How about using trac[1]? I can assist setting up and maintain it if you'd like. (It's also possible to use trac without svn if you do not want to use subversion.)
- I think it should be fairly easy to make mailman update the trac permission system.
- As for captchas there is a version of the trac SpamFilter[2] that implements this.
- Trac utilises the References and In-Reply-To headers.
What do you think? I can set up a demo during the weekend if it sounds interesting.
If it can do a nice integration with this mailing list (as described in this thread originally) then sure, why not. :)
Oh and I hope it's also possible to disable all the non-bugtracker stuff from it? Didn't it contain wiki and whatelse that I probably don't want messing with the existing Wiki..
Yes it contains Wiki. But what about having some kind of "unofficial wiki" there? This works very nice e.g. in Gentoo, where Gentoo-wiki is some kind of add-on to official documentation.
Láďa-----Original Message----- From: dovecot-bounces@dovecot.org [mailto:dovecot-bounces@dovecot.org] On Behalf Of Timo Sirainen Sent: Friday, March 23, 2007 7:36 PM To: Christian Skarby Cc: Dovecot Mailing List Subject: Re: [Dovecot] Bug tracking system
On Thu, 2007-03-22 at 10:33 +0100, Christian Skarby wrote:
How about using trac[1]? I can assist setting up and maintain it if you'd like. (It's also possible to use trac without svn if you do not want to use subversion.)
- I think it should be fairly easy to make mailman update the trac permission system.
- As for captchas there is a version of the trac SpamFilter[2] that implements this.
- Trac utilises the References and In-Reply-To headers.
What do you think? I can set up a demo during the weekend if it sounds interesting.
If it can do a nice integration with this mailing list (as described in this thread originally) then sure, why not. :)
Oh and I hope it's also possible to disable all the non-bugtracker stuff from it? Didn't it contain wiki and whatelse that I probably don't want messing with the existing Wiki..
Den 23-03-2007 19:36, Timo Sirainen skrev:
On Thu, 2007-03-22 at 10:33 +0100, Christian Skarby wrote:
How about using trac[1]? I can assist setting up and maintain it if you'd like. (It's also possible to use trac without svn if you do not want to use subversion.)
- I think it should be fairly easy to make mailman update the trac permission system.
- As for captchas there is a version of the trac SpamFilter[2] that implements this.
- Trac utilises the References and In-Reply-To headers.
What do you think? I can set up a demo during the weekend if it sounds interesting.
If it can do a nice integration with this mailing list (as described in this thread originally) then sure, why not. :)
Oh and I hope it's also possible to disable all the non-bugtracker stuff from it? Didn't it contain wiki and whatelse that I probably don't want messing with the existing Wiki..
Den 23-03-2007 20:35, Láďa skrev: Yes it contains Wiki. But what about having some kind of "unofficial wiki" there? This works very nice e.g. in Gentoo, where Gentoo-wiki is some kind of add-on to official documentation.
I think it is a good idea to have only one wiki. As opposed to the gentoo documentation, anyone has access to edit wiki.dovecot.org.
It is certainly possible to disable the trac.wiki-parts. Maybe it's posible to craft a plugin as described in http://trac.edgewall.org/ticket/2890 so that tickets easily can link to the official wiki pages. I guess there are good reasons to stay with MoinMoin, such as WYSIWYG-editing and language translations (menus). Currently I'm having a few other projects on the stack for the weekend, but I'll have a look as soon as possible. ;)
-- Vennlig hilsen
Christian Skarby Interhost ANS
On Fri, 2007-03-23 at 20:35 +0100, Láďa wrote:
Yes it contains Wiki. But what about having some kind of "unofficial wiki" there? This works very nice e.g. in Gentoo, where Gentoo-wiki is some kind of add-on to official documentation.
I could add an "UnofficialWiki" link to the main page, but I've no idea what people would want to write there :)
You are right, I missed the fact that the Dovecot wiki is editable for everyone so it doesn't make any sense.
-----Original Message----- From: dovecot-bounces@dovecot.org [mailto:dovecot-bounces@dovecot.org] On Behalf Of Timo Sirainen Sent: Monday, March 26, 2007 2:05 AM To: dovecot@dovecot.org Subject: Re: [Dovecot] Bug tracking system
On Fri, 2007-03-23 at 20:35 +0100, Láďa wrote:
Yes it contains Wiki. But what about having some kind of "unofficial wiki" there? This works very nice e.g. in Gentoo, where Gentoo-wiki is some kind of add-on to official documentation.
I could add an "UnofficialWiki" link to the main page, but I've no idea what people would want to write there :)
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!
-----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:
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.
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:
- 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
Timo Sirainen wrote:
- 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@cardgate.net
Curtis Maloney <cmaloney@cardgate.net> writes:
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.
I know other projects that might be interested in this solution. Emacs, for instance.
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@cardgate.net
-- Joakim Verona http://www.verona.se
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jan 22, 2007, at 5:19 AM, joakim@verona.se wrote:
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.I know other projects that might be interested in this solution. Emacs, for instance.
If anybody's interested in exploring this using Mailman as a starting
point, contact me off-list or join mailman-developers@python.org.
Cheers,
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRbS9SHEjvBPtnXfVAQIYWgP+PVG18hr6Y/3IDezu9QhxIKdke1NFnqGF FnWDTt0JPix/zw7x3CBgWN08xoZqouVHHF0lzXeQ8LyIhPsaB7PLOex/lKAcaDjU BpmeYgKMFHGtRhYr7ZT86ar9rlEiUbx8PrQupjDSiyuTxEZm8fcRzc8sl4m2l7Hp alqUjiY6nYs= =1yY7 -----END PGP SIGNATURE-----
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
participants (17)
-
Axel Thimm
-
Barry Warsaw
-
Charles Marcus
-
Christian Skarby
-
Curtis Maloney
-
Dick Middleton
-
Francisco Reyes
-
Frank Cusack
-
Gerard
-
joakim＠verona.se
-
Jochen Schulz
-
Johannes Berg
-
Láďa
-
Mark E. Mallett
-
scorch
-
Timo Sirainen
-
Udo Rader