Bug#532187: please mark bugs already closed by an upload in versioned view
On Fri, 13 Aug 2010, Bernhard R. Link wrote:
> * Don Armstrong <email@example.com> [100812 21:39]:
> > Yeah, the old closed code removed the pending tag. I'm not sure if
> > that's ideal, however.
> What is the current state of this? From the bahaviour it had when
> I filed the bug (I think 2009-06-07), the bugs were not shown as pending
> but as outstanding once it hit the archive for some architectures.
> Having looked at the code 
> the only way I see this can happen when pending tags are removed
> on -done (and it looks like there is still some code that might do such
> a thing, but I did not verify if it is life).
It does for nnn-done, but the code I just wrote doesn't do it for closed.
> > The main problem with this is that it changes the syntax of
> > max_buggy, which has all kinds of far-reaching effects.
> I assumed since max_buggy is not exported and the only other caller
> is easy to adopt it is easier to change that instead of adding some
It itself isn't exported, but bug_presence is, and there are loads of
other things which consume the output of bug_presence.
> > It seems this can be calculated as a separate call to a different
> > function than max_buggy, and just populate another field that
> > get_status returns instead of further overloading the pending
> > field.
> As pending contains pending-fixed I assumed the new state to fit
> naturally in there. (Though it is indeed already quite crowded. If
> pending had been already replaced with something less crowded (and
> the field that means a bug is not pending if it has value pending
> not called pending) would have quite helped me reading the code).
You've identified precisely why I don't want to overload that field
any more. I didn't design that initially, and I want to go away from
>  btw: When adding new code please consider writing longer names,
> all those abbreviations make it really hard to figure out what the
> code is doing. I do not know how natural it is for native speakers
> to consider ttl to mean title for example, but before I found some
> instance of an longer variable name I did could not get its meaning.
I didn't write that code; it's on the list of code to be rewritten.
I learned really early the difference between knowing the name of
something and knowing something
-- Richard Feynman "What is Science" Phys. Teach. 7(6) 1969