[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

* Don Armstrong <don@debian.org> [100812 21:39]:
> On Thu, 12 Aug 2010, Bernhard R. Link wrote:
> > * Bernhard R. Link <brlink@debian.org> [090608 19:37]:
> > > * Don Armstrong <don@debian.org> [090607 23:23]:
> > > > 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.
> > >
> > > At least the upload pending bugs are not suddenly more outstanding then
> > > before the upload.
> >
> > 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.

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.

> 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

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

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

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.

Reply to: