Re: forwarding bugs upstream - opt-in, delayed, automated
On 09/13/2011 03:14 PM, Stefano Zacchiroli wrote:
> - enable people to subscribe to bug traffic only if it matches specific
> tags (the idea being of forwarding upstream only the traffic for
> "confirmed" bugs)
> - add a DELAYED-like mechanism where upstream is notified of a bug only
> if the package maintainer fails to "deal with" the bug in a specific
> timeframe, say, 10 days ("deal with" may be defined in various ways,
> e.g.: "post to the bug log", "closes the bug", details need to be
> fleshed out a bit on this point)
> Both features will most likely end up being proper feature requests
> against the BTS and/or the PTS. They look completely non-intrusive with
> respect to what we already offer and they will be opt-in anyhow. The
> DELAYED part is not entirely trivial to implement, but Steve is
> interested in helping out.
The DELAYED one should be easy to implement as the BTS SOAP interface
 already has the notion of a log_modified attribute which holds the
DateTime of last update of the bug (and a date attribute which is the
DateTime of creation of the bug).
The tags attribute in the BTS SOAP interface obviously contains the bug
tags, but I'm unsure if that would be enough. It could be a start for
confirmed, security and the like though.
Should it be implemented in the PTS? How would DELAYED be defined, a
fixed amount of days old? How would the selection of the tags be done?