Monday bug triage report (2022-04-22 -> 2022-04-24)
lucas.kanashiro at canonical.com
Wed Apr 27 19:12:28 UTC 2022
On Wed, Apr 27, 2022 at 3:55 PM Bryce Harrington <
bryce.harrington at canonical.com> wrote:
> On Mon, Apr 25, 2022 at 12:04:47PM -0300, Lucas Kanashiro wrote:
> > Bugs last updated between 2022-04-22 (Friday) and 2022-04-24 (Sunday)
> > inclusive
> > Date range identified as: "Monday triage"
> > Found 10 bugs
> > The number of bugs was lower than I was expecting because of the Jammy
> > release. Comments below:
> > # https://pad.lv/1970076 - (New) [openssh] - User
> > process fault: interruption code 0011 ilc:3 on SSH cli…
> > This is a bug in a virtualized environment in s390x, I was not able to
> > reproduce it yet. It'd be helpful if Christian could take a quick look to
> > see if it rings a bell to him.
> > # https://pad.lv/1961633 - +(Triaged) [multipath-tools] -
> > dropping d/p/kpartx-Improve-finding-loopback-devic…
> > This bug is in our backlog and has not been touched in 60 days. I think
> > 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
> 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
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.
Thanks for working on this tool!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ubuntu-server