On 2012-12-25 22:23, Adam D. Barratt wrote:
> [...]
IRC chat log for future reference.
~Niels
<adsb> nthykier: I'm attempting to write an explanation for what's going on in
#673063, although I'm not sure how helpful it'll turn out to be
<adsb> I'm now remembering how much figuring that code out in the first place
made my head hurt
<nthykier> adsb: It is not a priority, but I would like us to eventually get
that code path straight so we can play around with different algorithms :)
<adsb> I know what it's doing, it's just explaining it without it getting too
waffly or confused :)
<nthykier> I don't mind if it is terse. Clarity is more important than
fluent/interesting language.
<nthykier> alternatively if it can be broken into cases, that would probably
work too
<nthykier> we just need it until one of us comes up with smarter and more
self-descriptive rewrite of it :P
<adsb> well, I've sent what I can come up with at the moment. had to go back
through the history and remind myself of a couple of things (like why I added
the else)
<nthykier> adsb: Your comment/commit suggests that this lundo part is only
relevant when processing hints. So in the main run lundo could be empty and it
shouldn't make any difference?
<nthykier> Also, can you produce a test cases for us breaking the else branch?
<adsb> that sounds right, yeah. and probably, but not tonight :)
<nthykier> okay, because I suspect that right that lundo might not be empty in
the main run...
<nthykier> (and I don't mind waiting a day or two on a new test case :D )
<adsb> I'll add a note, not sure how quick it'll be. a chunk of tomorrow will
be travelling home and thursday's back to work
<nthykier> great
<adsb> I know it fixed a real issue we had at the time. whether I can remember
more than I managed to deduce in that mail is a different question
<nthykier> Well, we know now it will involve at least an "easy" or "hint" (I
suspect it could also involve a "force-hint", but...)
<adsb> or I chose really bad names or misunderstood what was going on :P but
yeah, logically it should be a hint of some kind
<adsb> nthykier: fwiw, looking through my mail history suggests it was #625792
<adsb> why I didn't record that in the commit message... meh
<nthykier> to be honest, I am not quite happy with code-flow vs. your
explaination... I still see "if binary in binaries[parch][0]: <do stuff>" (line
1936) as the "if binary was hijacked: <do stuff>"
<nthykier> To me it looks like the binary will not be in "binaries[parch][0]"
if it was built from the source
<nthykier> (From "del binaries[parch][0][binary]" in line 1908)
<adsb> it won't be if it was built from the source we're about to migrate,
indeed. I thought I'd explained that; obviously not :(
<adsb> s/the source/old version of &/
<adsb> they're both essentially testing for hijacks. the difference is that the
else branch gets hit if the package it's being hijacked from was processed
earlier in the same hint, in which case the package will no
longer be in binaries[parch][0]
<adsb> well, the else branch is more movement rather than hijacks - i.e.
package A stops producing binary X, package B starts migrating it, so they need
to migrate at the same time
<adsb> s/migrating/producing/
<nthykier> I suspect that is a good "note-to-self" for writing that test case
<nthykier> but I also notice that if we merged "affected" for all migration
items involved in a hint, that else branch is starting to look redundant
<nthykier> (and we might be saving a few installability checks)
<adsb> it would also help if my connectivity would stop siezing up :(
<nthykier> mind if I attach this part of the IRC log to the bug for future
reference?
<adsb> if you think it'll help, sure :)
