note: followup to debian-debbugs@lists.debian.org Well, the new year is fast approaching(for some of you, it's already hear). So, I thought it'd be nice if we started it off with a nice announcment.
Debbugs is being replaced. Before you get your panties all in a bunch, it's being replaced with Debbugs 2.0. This is a mostly rewritten from the ground up new system, taking advantage of modern technologies, and even implementing new ones. For those wanting to see the current codebase, please visit http://cvs.doogie.org/debbugs/?cvsroot=Debian The core of Debbugs is now an abstract service engine. No longer will the code contain a huge if block, that just does pattern matching. Each command or action is now a module, in this service engine. This has made the code much more maintainable, even in this early development stage. Also, this service engine has a concept of ACLs, so we can now protect various commands from being executed unless the current user has authenticated thru some means. Also, all database access(.status and .log) goes thru abstract functions. This is to allow for alternate storage mechanisms in the future(currently, the only existing one if for the current file layout). Not all features have been implemented in the new code base. However, *all* status manipulation commands for [EMAIL PROTECTED] are done. Most information requests for [EMAIL PROTECTED] are yet to be implemented. The only major new feature implemented so far is transaction support. You'll be able to wrap your command lists with 'begin' and 'commit'/ 'rollback', to ensure everything works, or none of it. Additionally, all mail is done with an external template system. The main debbugs code itself is not concerned with when mails get set. The generic service engine sends the mails for it. The above is just the current state of the code. It is no where near usable by the public. [EMAIL PROTECTED], [EMAIL PROTECTED] are not yet implemented. No incoming mail is being parsed. There is still a long way to go. But, with this code base, implementing each feature is rather straight forward. Now, on to the discussion part of this email. What I would like to see in the discussion that results from this email, are new features people would like to see implemented. I'll start it off with the list of features I plan on implementing. * Bug dependencies(#129781) * Package/Source/Bug/Maintainer subscriptions(this will swallow a large part of the PTS) * Make use of pgp/gpg sigs on mails, to enable various commands. For example, this could be used by the Release Manager to tweak certain tags/status bits, but disallow these commands for others. * Per email/maintainer/package flags. This could be used to keep the acks from being sent(#174503). * Version tracking. * Add priority(difficulty?(144633)) tracking(different from status and severity). * A free-form notes field, for bugs, packages, and sources. * Pagination on all cgi output(various bug#). * unarchive command to list of approved users. * Bug owners(#134791) * Package/Source based mbox fetching. * Swallow bugscan? * internal: automated test system/framework The above list is the major new features I plan on adding, and is not all inclusive. Please discuss major new features, not minor cosmetic ones(as these are easy to fix anyways, so why waste the bandwith).