Debian Bug report logs - #532187
please mark bugs already closed by an upload in versioned view

Full log

Message #37 received at [email protected] (full text, mbox, reply):

Received: (at 532187) by bugs.debian.org; 13 Aug 2010 20:54:55 +0000
From [email protected] Fri Aug 13 20:54:55 2010
X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02
	(2008-06-10) on busoni.debian.org
X-Spam-Level: 
X-Spam-Bayes: score:0.0000 Tokens: new, 8; hammy, 148; neutral, 132; spammy,
	3. spammytokens:0.987-1--H*r:27916, 0.940-+--view, 0.924-+--natural
	hammytokens:0.000-+--H*r:nullmailer, 0.000-+--H*u:1.5.20,
	0.000-+--H*UA:1.5.20, 0.000-+--H*u:2009-06-14, 0.000-+--H*UA:2009-06-14
X-Spam-Status: No, score=-7.2 required=4.0 tests=AWL,BAYES_00,FROMDEVELOPER,
	HAS_BUG_NUMBER,URIBL_CNKR autolearn=ham
	version=3.2.5-bugs.debian.org_2005_01_02
Return-path: <[email protected]>
Received: from rzlab.ucr.edu ([138.23.92.77])
	by busoni.debian.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.69)
	(envelope-from <[email protected]>)
	id 1Ok1HC-0002N6-Il
	for [email protected]; Fri, 13 Aug 2010 20:54:55 +0000
Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1])
	by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7DKsq8A019690
	for <[email protected]>; Fri, 13 Aug 2010 13:54:52 -0700
Received: (from remotemail@localhost)
	by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id o7DKsqWI019689
	for [email protected]; Fri, 13 Aug 2010 13:54:52 -0700
Received: (nullmailer pid 27916 invoked by uid 1000);
	Fri, 13 Aug 2010 20:54:49 -0000
Date: Fri, 13 Aug 2010 13:54:49 -0700
From: Don Armstrong <[email protected]>
To: [email protected]
Subject: Re: Bug#532187: please mark bugs already closed by an upload in
 versioned view
Message-ID: <[email protected]>
References: <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <[email protected]>
User-Agent: Mutt/1.5.20 (2009-06-14)

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

Send a report that this bug log contains spam.