ANNC: New Debbugs
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 control@bugs are done. Most
information requests for control@bugs 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. ###@bugs, submit@bugs 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).
Reply to: