Don Armstrong writes ("Re: Bug#886645: want guidance for changelogs when
history is merge-ish"):
> On Tue, 09 Jan 2018, Ian Jackson wrote:
> > * 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?]
"fixed" in a later version has to trump "found" in an earlier version.
Specifically, consider this case:
4
/ \
/ \
/ \
/ \
3 2 fixed
\ /
\ /
\ /
\ /
1 found
By my algorithm, nodes are annotated this way:
4 { 1: fixed }
/ \
/ \
/ \
/ \
3 2 fixed
{ 1:found } \ / { 1: fixed }
\ /
\ /
\ /
1 found
{ 1: found }
Note that this trumping of foundness for version B by fixedness for
version B only occurs at a node one of whose ancestors has B for an
ancestor and is marked fixed. Ie, like this in the general case:
V
/ \
{ B: found } X \
/ ??? { B: fixed }
Z \
` \
` W fixed { B: fixed }
??? |
` ???
` /
` /
B found
|
I think you are worried about the case where an ancestor of Z
reintroduces the bug and a "found" mark there would be overwritten.
But if it does then X would be labelled
{ B: found, Z: found }
or some such. The { B: found } gets squashed by { B: fixed }
but the { Z: found } remains so V gets { B: fixed, Z: found }
and is considered buggy.
This is exactly right. What we are modelling here is this reasoning:
Suppose B is marked found, and W, a descendant of B, is marked
fixed. Then W must have a bugfix for the version of the bug which
is in B. That bugfix will be inherited by all of W's descendents,
even ones which also inherit the bug by other routes.
If the bug were reintroduced we get something like this:
4 { 1: fixed, 2.5: found }
/ \
/ \
/ 2.5 found { 1: fixed, 2.5: found }
/ \
3 2 fixed
{ 1:found } \ / { 1: fixed }
\ /
\ /
\ /
1 found
{ 1: found }
What this is doing is effectively treating every "found" as a separate
bug and seeing if each version of interest has a fix for it, where "a
fix for it" is inferred to exist in any package version which is
marked fixed and which is descended from the bug.
> 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.
Heh.
I don't think this is the most important thing to be doing.
> > 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.
Good point.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
