Monday bug triage report (2022-04-22 -> 2022-04-24)
bryce.harrington at canonical.com
Wed Apr 27 19:51:04 UTC 2022
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'
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. :-)
More information about the ubuntu-server