At 29 Oct 2002 10:19:03 -0500, Neal H. Walfield wrote: > I certainly appreciate these arguments, however, I would appreciate it > (as I think would others) if you could briefly enumerate what > separates bugcomm from the others. That is, which design issues does > bugcomm try to correct; just calling it better does not mean anything > without arguments for why it is so.
You are right, but I'm too lazy to enumerate all of them, so I describe some of them here: * Followups using your favorite mailer You can add followups via e-mail, like JitterBug and Debian's BTS. Original bug reports can be sent to an arbitary number of mailing lists. * No need to use any special client You can report bugs using your favorite web browser. You can add followups using your favorite mailer. * Dynamic customization via WWW You don't have to stop the system to change most of settings. * Support for multiple projects You can manage an arbitary number of projects in a single system. * No login, no password You don't have to create a user at all. So you don't have to remember one more password. All authentications are done via e-mail. * Arbitrary bug attributes You can add arbitary fields associated with bugs. You can use two types of fields, text fields and selection fields. You can also restrict text fields to a pattern using a regular expression. * Extensibility Because it is written in the scripting language Ruby and well-designed, it is easy to modify it. BugCommunicator has some other advantages (such as I18N), but I guess I won't have to list up any more, because I don't know any other BTS which fulfills those points in good quality. I don't say that BugCommunicator is the best BTS for everyone, but if you need a flexible, simple, and still powerful BTS, BugCommunicator could be the best choice. Okuji _______________________________________________ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
