[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#532187: please mark bugs already closed by an upload in versioned view

On Fri, 13 Aug 2010, Bernhard R. Link wrote:
> * Don Armstrong <don@debian.org> [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 [1]
> 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
> complexity.

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

> [1] 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.

Don Armstrong

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

http://www.donarmstrong.com              http://rzlab.ucr.edu

Reply to: