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

From: "Bernhard R. Link" <[email-masked]>
Date: Sun, 7 Jun 2009 12:36:42 +0200

Package: debbugs

When a package is uploaded to unstable and not yet built and installed
on all architectures, debugs output is quite confusing, as all bugs
are still displayed as "Outstanding".

Even worse is that bugs lose their "Pending Upload" category in the
display (which I guess is sensible for dist=stable), which means that
upon upload a bug will move from "Pending Uploaded" to "Outstanding",
making the dist=unstable view mostly useless until all old version
in the archive are replaced with new ones.

I want to suggest the following new behaviour: Add a new category, for
example "Pending migration bugs" or "From some architectures bugs",
in which a bug is put if it:

a) is resolved in at least one version found in the distribution selected
b) is outstanding in at least one version found in the distribution selected
c) the largest version from a) is bigger than the largest version from b)

Thanks in advance,
	Bernhard R. Link

---

From: Don Armstrong <[email-masked]>
Date: Sun, 7 Jun 2009 14:23:24 -0700

On Sun, 07 Jun 2009, Bernhard R. Link wrote:
> When a package is uploaded to unstable and not yet built and
> installed on all architectures, debugs output is quite confusing, as
> all bugs are still displayed as "Outstanding".

This is because they are outstanding. If you want to look at the view
from a particular architecture (say the one you upload) apend
arch=i386 or arch=source or similar.

Don Armstrong

-- 
We must realize that today's Establishment is the New George III.
Whether it will continue to adhere to his tactics, we do not know. If
it does, the redress, honored in tradition, is also revolution.
 -- William O. Douglas _Points of Rebellion_

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

---

From: "Bernhard R. Link" <[email-masked]>
Date: Mon, 8 Jun 2009 21:37:50 +0200

* Don Armstrong <[email-masked]> [090607 23:23]:
> This is because they are outstanding.

At least the upload pending bugs are not suddenly more outstanding then
before the upload.

> If you want to look at the view

While it is possible to do this or to just remove the dist=unstable,
it would be much nicer, if it would be something useful without extra
intervention.

I think such a new "Outstanding on some architectures only" category
would massively improve the current situation.

Hochachtungsvoll,
	Bernhard R. Link

---

From: "Bernhard R. Link" <[email-masked]>
Date: Thu, 12 Aug 2010 23:13:40 +0200

> At least the upload pending bugs are not suddenly more outstanding then

If I understand the code correctly, then the pending tag seems to no longer
exists after closing the bug. No idea if not removing that now that
closed no longer means closed in another way to improve the situation
here.

> would massively improve the current situation.

I've attached an patch that might do what I think it should do. I've
no idea how I can test debbugs and my perl is not that good, but the
changes needed seem to be relatively trivial.

Thanks in advance,
        Bernhard R. Link
=== modified file 'Debbugs/Status.pm'
--- Debbugs/Status.pm	2010-02-05 07:38:18 +0000
+++ Debbugs/Status.pm	2010-08-12 21:11:15 +0000
@@ -913,13 +913,14 @@
 	  @source_versions{@sourceversions} = (1) x @sourceversions;
 	  # If the bug has not been fixed in the versions actually
 	  # distributed, then it cannot be archived.
-	  if ('found' eq max_buggy(bug => $param{bug},
+	  my $max_buggy = max_buggy(bug => $param{bug},
 				   sourceversions => [keys %source_versions],
 				   found          => $status->{found_versions},
 				   fixed          => $status->{fixed_versions},
 				   version_cache  => $version_cache,
 				   package        => $status->{package},
-				  )) {
+				  );
+	  if ('found' eq $max_buggy or 'partly-fixed' eq $max_buggy) {
 	       print STDERR "Cannot archive $param{bug} because it's found\n" if $DEBUG;
 	       return $cannot_archive;
 	  }
@@ -1098,6 +1099,9 @@
 	  if ($presence eq 'fixed') {
 	       $status{pending} = 'done';
 	  }
+	  elsif ($presence eq 'partly-fixed') {
+	       $status{pending} = 'archmissing';
+	  }
 	  elsif ($presence eq 'absent') {
 	       $status{pending} = 'absent';
 	  }
@@ -1111,8 +1115,9 @@
                                  ...
                                 );
 
-Returns 'found', 'absent', 'fixed' or undef based on whether the bug
-is found, absent, fixed, or no information is available in the
+Returns 'found', 'absent', 'fixed', 'partly-fixed' or undef based on
+whether the bug is found, absent, fixed, found and fixed,
+or no information is available in the
 distribution (dist) and/or architecture (arch) specified.

@@ -1339,9 +1344,13 @@
 				 package => $package,
 				);
 	       if ($buggy eq 'found') {
-		    return 'found';
+		    $maxbuggy = 'found';
 	       } elsif ($buggy eq 'fixed') {
-		    $maxbuggy = 'fixed';
+		    if ($maxbuffy eq 'found') {
+		         $maxbuggy = 'partly-fixed';
+		    } else {
+		         $maxbuggy = 'fixed';
+		    }
 	       }
 	  }
      }

=== modified file 'cgi/common.pl'
--- cgi/common.pl	2007-06-26 17:44:40 +0000
+++ cgi/common.pl	2010-08-12 19:37:00 +0000
@@ -87,7 +87,7 @@
 );
 my @common_grouping = ( 'severity', 'pending' );
 my %common_grouping_order = (
-    'pending' => [ qw( pending forwarded pending-fixed fixed done absent ) ],
+    'pending' => [ qw( pending forwarded pending-fixed archmissing fixed done absent ) ],
     'severity' => \@gSeverityList,
 );
 my %common_grouping_display = (
@@ -102,6 +102,7 @@
 	"done"		=> "resolved",
 	"forwarded"	=> "forwarded to upstream software authors",
 	"absent"	=> "not applicable to this version",
+	"archmissing"	=> "outstanding one some architectures only",
     },
     'severity' => \%gSeverityDisplay,
 );

=== modified file 'cgi/pkgreport.cgi'
--- cgi/pkgreport.cgi	2010-04-16 17:06:52 +0000
+++ cgi/pkgreport.cgi	2010-08-12 21:03:15 +0000
@@ -196,8 +196,9 @@
     "status" => [ {
         "nam" => "Status",
         "pri" => [map { "pending=$_" }
-            qw(pending forwarded pending-fixed fixed done absent)],
+            qw(pending forwarded pending-fixed archmissing fixed done absent)],
         "ttl" => ["Outstanding","Forwarded","Pending Upload",
+                  "Resolved on some Architectures",
                   "Fixed in NMU","Resolved","From other Branch"],
         "def" => "Unknown Pending Status",
         "ord" => [0,1,2,3,4,5,6],

---

From: Don Armstrong <[email-masked]>
Date: Thu, 12 Aug 2010 14:39:21 -0700

On Thu, 12 Aug 2010, Bernhard R. Link wrote:
> If I understand the code correctly, then the pending tag seems to no
> longer exists after closing the bug. No idea if not removing that
> now that closed no longer means closed in another way to improve the
> situation here.

Yeah, the old closed code removed the pending tag. I'm not sure if
that's ideal, however.

> > I think such a new "Outstanding on some architectures only"
> > category would massively improve the current situation.
> 

The main problem with this is that it changes the syntax of max_buggy,
which has all kinds of far-reaching effects. 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.

In fact, I think what you may actually want to know is whether the bug
is -done or not, not whether it's even fixed in a particular version
in that archive. But I'm not totally sure about that.

All of that said, thanks for taking the impetus to write up a patch
for this.

Don Armstrong

-- 
life's not a paragraph
And death i think is no parenthesis
 -- e.e. cummings "Four VII" _is 5_

---

From: "Bernhard R. Link" <[email-masked]>
Date: Fri, 13 Aug 2010 15:09:08 +0200

> Yeah, the old closed code removed the pending tag. I'm not sure if

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).

If now pending bugs are now no longer "Outstanding" once they are closed
but not yet built everywhere, then the severity of this missing feature
gets massively decreased.

> 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 seems this can be

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).

> in that archive. But I'm not totally sure about that.

I personally would prefer to have bugs marked open in distributions
where they are not fixed but listed in distributions where it still
needs some action. But those only needing buildd action ideally
in a group of they own but at least not inflating priority
(Pending => Outstanding) upon upload.

	Bernhard R. Link

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

---

From: Don Armstrong <[email-masked]>
Date: Fri, 13 Aug 2010 13:54:49 -0700

> 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.
> 
> 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

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.

> 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