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

Don Armstrong <[email protected]>
Newsgroups gmane.linux.debian.devel.debbugs
Message-ID <20100813205449.GL17623__16333.658542908$1281733041$gmane$org@teltox.donarmstrong.com>
On Fri, 13 Aug 2010, Bernhard R. Link wrote:
> * Don Armstrong <[email protected]> [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
it.

> [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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.