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

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

* Don Armstrong <don@debian.org> [090607 23:23]:

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

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

* Bernhard R. Link <brlink@debian.org> [090608 19:37]:

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.

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

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

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

* Don Armstrong <don@debian.org> [100812 21:39]:

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.

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.

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

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.

It does for nnn-done, but the code I just wrote doesn't do it for closed.

It itself isn't exported, but bug_presence is, and there are loads of
other things which consume the output of bug_presence.

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.

I didn't write that code; it's on the list of code to be rewritten.


Don Armstrong