On Tue, 09 Jan 2018, Ian Jackson wrote: > | What about making the BTS support DAGs which are not trees? I think > | something like this would be useful, but I don't personally have a > | good idea on how this could be specified using the changelog or how > | bug fixed/found/absent should be propagated in the DAG. If you have > | better ideas, email me! > > Without thinking about it excessively hard, I have three suggestions: > > 1. Use the following algorithm for constructing the DAG (which may now > contain merges):
[...] > 2. If we don't want to create nodes for un-uploaded versions: [...] > For both the above, use the following algorithm for fixed/found > propagation: > > * Annotate every node with an "bug map", > <version> |-> Undef | Found | Fixed > * Each node inherits the merger of the bug map of its parents > When merging, for each key we take the largest value for > any parent where Undef < Found < Fixed I'm leery of this, because it's not conservative. If the inheritance method preferred found over fixed, that might be workable. Another concern is the complexity, and the lack of a mechanism to prune edges. [Though maybe that won't be used in practice?] But that said, we do have historical changelog records for almost all uploads to Debian from about potato, so it would be possible to actually test these approaches and think about them in detail. [dgit and screen look like two promising candidates; I could supply a tarball of their changelog versions in order if that was useful.] I've currently got some other things on my plate (database, changing templating engine) for Debbugs, but I'm happy to facilitate anyone working in this area. > 3. Alternatively, here is a non-DAG based algorithm: > > * For each version, we determine whether it is considered to > have the bug as follows: > > * Look at its changelog. Work backwards through changelog entries > until we find a version which is tagged "found" or "fixed". That > is the answer. (If we don't find such a version, the bug is > considered absent.) This means that if a changelog ever deleted a version (on purpose or accidentally) that bugs which were marked found in that version would suddenly stop being buggy in future versions, even if they hadn't been fixed. > That algorithm involves storing a (possibly entirely different) list > of versions for every version of interest. We actually have that stored currently (but we don't use it for anything but rebuilding the version tree if we have to). So that wouldn't be too much difficulty. -- Don Armstrong https://www.donarmstrong.com The sheer ponderousness of the panel's opinion [...] refutes its thesis far more convincingly than anything I might say. The panel's labored effort to smother the Second Amendment by sheer body weight has all the grace of a sumo wrestler trying to kill a rattlesnake by sitting on it---and is just as likely to succeed. -- Alex Kozinski, Dissenting in Silveira v. Lockyer (CV-00-00411-WBS p5983-4)
