Monday bug triage report (2022-04-22 -> 2022-04-24)

[Lucas Kanashiro]

On Wed, Apr 27, 2022 at 4:51 PM Bryce Harrington <
bryce.harrington at canonical.com> wrote:

> On Wed, Apr 27, 2022 at 04:12:28PM -0300, Lucas Kanashiro wrote:
> > > > # https://pad.lv/1961633 - +(Triaged)       [multipath-tools]   -
> > > Consider
> > > > dropping d/p/kpartx-Improve-finding-loopback-devic…
> > > >
> > > > This bug is in our backlog and has not been touched in 60 days. I
> think
> > > we
> > > > should consider this when merging multipath-tool during the KK cycle.
> > > > Bryce, is there any way to get this linked to the merge bug that your
> > > > tooling will create?
> > >
> > > There's not, however this request has come up a couple times before, so
> > > rule of three suggests we do need a way to track these.
> > >
> > > Previously I've just stuck them in my personal todo list to mention in
> > > bug reports, and I can do that in this case too.  (I'm probably going
> to
> > > take the merge for multipath-tools this cycle anyway.)
> > >
> > > But to solve this more generally:
> > >
> > > The tooling already knows how to look for bugs with tags, so what if
> > > during the regular triage process we tag such bugs with an agreed on
> > > tag.  Then when the merge board is generated, the tools would query any
> > > such tagged bugs still open for the given package and itemize them in
> > > the bug report description.
> > >
> > > Looking at https://wiki.ubuntu.com/Bugs/Tags, there is already a
> > > 'packaging' bug tag, defined as a packaging related problem (as opposed
> > > to 'needs-packaging' which marks packaging of software not yet
> > > packaged).
> > >
> > > Presumably any bug marked 'packaging' against one of our packages
> > > probably *should* be considered during merge anyway, so if we used it
> > > for this purpose it doesn't seem like we'd be misusing or overloading
> > > it.
> > >
> > > WDYT?
> > >
> >
> > I liked the proposed approach Bryce. What I am not sure about is using
> the
> > existent 'packaging' tag, from the page you linked "The bug is likely to
> be
> > a packaging mistake", some of those bugs are not necessarily a packaging
> > mistake but a reminder to revisit an upstream bug or reconsider part of
> the
> > delta we carry.
>
> It's possible that definition was not adequate in describing how the tag
> has been used in practice.  Take a look at the bugs with the 'packaging'
> tag:
>
>     https://launchpad.net/ubuntu/+bugs?field.tag=packaging
>
> There seem to be a number of bugs about reconsidering delta, and
> especially the wishlist bugs look like they involve upstream related
> considerations.  Certainly look like the types of bugs we'd want to at
> least know about, when merging a package.  The 'packaging' tag is listed
> under "Generic bug tags" so I imagine it was intended to be reasonably
> broad in scope already.  So packaging mistake may just have been a bit
> too narrow in defining the tag, and I doubt there would be an issue if
> we also used it for similar needs.
>
> 'packaging' also has the benefit of being relatively easy to remember. :-)
>

Fair enough. I did not check the bugs with the 'packaging' tag, thanks for
the link.

In that case, I think we can use the 'packaging' tag, and we should update
the wiki page with a better description :)

Lucas Kanashiro.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20220427/10d97f70/attachment-0001.html>