On Tue, Apr 30, 2002 at 01:41:55AM -0500, Adam Heath wrote: > On Sun, 28 Apr 2002, Sami Haahtinen wrote: > > but wouldn't this bring us back to the original problem where bts gets > > flooded with closing requests when the packages get moved to the > > archive? > > Does BTS have somekind of priority queue? if so, this could be used to > > drop request the final closing of the bugs (or to add more states to the > > bugs: fixed+testing, fixed+unstable) without a major performance > > issues. > This is not a problem. The bts processes all mails serially(once every 15 > minutes). > Previously, the bts would wait for each email response to be delivered, before > processing the next bug email. However, Anthony Towns modified the code to > have the emails sent in the background, so that the 15 minute queue runs very > fast. > > i really do think that this sort of major tracking would be needed to > > see which of the bugs are really open in testing and stable. > If there is consensus about this issue, I will implement the states needed in > the BTS to manage this. Then, it is only up to someone modifying dinstall to > send the new state change mails(probably simple, just changing a mail > template). I'm assuming that any new state implemented would also have bearing on the ordering of the bugs on BTS web pages (e.g., open bugs at the top, then pending bugs, fixed (NMU) bugs, pending-closed bugs, and finally closed bugs)? If so, that seems to neatly eliminate most of the arguments for adding such a state -- if bug submitters already aren't looking down at the bottom of the page for relevant bugs, how will adding a new category help? Steve Langasek postmodern programmer
Attachment:
pgpGtSFEdRqsO.pgp
Description: PGP signature