On Wed, Apr 27, 2022 at 4:51 PM Bryce Harrington < [email protected]> 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.
-- ubuntu-server mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
