[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Processed: block 680670 with 688793, tagging 680670



On Sun, 2012-09-30 at 09:56 -0400, Antoine Beaupré wrote:
> On 2012-09-30, Adam D. Barratt wrote:
> > How is the unblock request blocking the fixing of the bug? The bug is
> > already fixed and it's not even blocking the transition of the fix,
> > given that the unblock was added.
> 
> True, it doesn't. However, there was nothing in the bug report here
> refering to the unblock request, so I think it is good practice to refer
> to that bug.

It seems an odd (mis)use of the tag, imo. It /might/ make more sense if
there was some contention or delay surrounding the unblock request but
adding it after the package has already been unblocked seems at best
redundant.

Marking the release.d.o bug as affecting the other package would seem a
more reasonable approach if you really need some indication on the
package's BTS pages.

> >> > tags 680670 + pending
> >> Bug #680670 {Done: Gaudenz Steinlin <gaudenz@debian.org>} [obnam] obnam: add_key doesn't encrypt symmetric key with new key
> >> Added tag(s) pending.
> >
> > Marking an already closed bug as pending is slightly unusual too, given
> > the standard meaning of "an upload will be made soon".
> 
> How else should we show bug squashers to not worry about this bug
> through metadata (as opposed to spending the 5-10 minutes to look into
> it? :)

How about using the correct piece of metadata, which was already set -
i.e. the fact that the bug is closed and marked as fixed in a version of
the package which is in unstable? :-)

Bugs which are marked as fixed in unstable but still affecting testing
might need someone to look in to why they're not migrating, but that
requires looking at the excuses and/or checking release.d.o bugs; I
wouldn't necessarily expect them to be on the radar of people looking
through the BTS for random bugs to squash in unstable. I could be wrong
of course...

Regards,

Adam


Reply to: