Hi, On Wed, Apr 27, 2022 at 3:55 PM Bryce Harrington < [email protected]> 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] - > 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. Thanks for working on this tool! Lucas Kanashiro.
-- ubuntu-server mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
