Re: ANNC: New Debbugs
On Tue, Dec 31, 2002 at 04:54:53PM -0600, Adam Heath wrote:
> note: followup to debian-debbugs@lists.debian.org
note: I'm not subscribed to debian-debbugs so please cc me.
> 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.
Cool.
> 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.
Ahh then it will be a LOT easier to extend!
> 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.
And I'll suggest some new ones, see below.
> 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.
subscribe bugnr email
and
unsubscribe bugnr email
would be really nice.
> 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)
This is the part where I have some (nice?) ideas that I would like to
be implemented.
*) Create packagename@ alias.
- When an email gets sent to packagename@bugs.debian.org a bug number
is create, just as when sent to submit@.
This way a new user would not have to learn to write pseudo headers.
The pseudo header can still be accepted but is not needed (i.e. optional)
to indicate which package to send to.
- submit@ can still be used but is not needed.
*) When email is sent to the user and mainainer about a bugnr, the
Reply-To: field should be set to bugnr@ only.
- Users who send information about the bug should automatically be subscribed
to the bug number.
- The ones subscribed to the package should also recieve information (of
course).
- This way we always get all information back to the bug tracking system.
Both the maintainer and the submitter communicates through the bts.
*) New commands should be accepted (to control@)
(un)subscribe bugnr email
What do you think about this system?
> * 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).
That would be a nice thing. The subscription system above would give a
good infrastructure on this, right? The initial submitter gets an
acc (when sending to packagename@ and submit@). In the rest of the time
he/she will get the email back (with some extra text in top/bottom maybe).
> * 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).
Regards,
// Ola
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Annebergsslingan 37 \
| opal@lysator.liu.se 654 65 KARLSTAD |
| +46 (0)54-10 14 30 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
Reply to: