14:52 <cpaelzer> #startmeeting Weekly Main Inclusion Requests status - bonus
14:52 <meetingology> Meeting started at 14:52:55 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
14:52 <meetingology> Available commands: action, commands, idea, info, link, nick
14:53 <sarnold> I'd like to plant the seed of an idea if there'd be gains in replacing the giant flowchart/state diagram of doom with something more like the kernel team SRU workflow
14:53 <sarnold> here's a nice example bug https://bugs.launchpad.net/kernel-sru-workflow/+bug/1983335
14:53 <cpaelzer> I missed an "Any other business"
14:53 <cpaelzer> #topic Any other business?
14:53 <sarnold> with the different phases of the review spelled out, individuals or teams assigned to each, status indicators on each..
14:53 <didrocks> oh, basically, all stages in the bug targets?
14:54 <cpaelzer> has anybody been in volved in creating this and can advise us?
14:54 <slyon> would be more of a linear process
14:54 <sarnold> I think it'd complicate things like bionic vulkan-tools, but I think it would have other simplifying efforts
14:54 <cpaelzer> mutli-release reviews would become multiple bugs
14:54 <sarnold> but the transition effort might cost more than any of us can afford
14:54 <didrocks> yeah, I wonder how unlinear would work out, see if we can serialize that to a stack rollbacking to top if needed with higher priority
14:54 <cpaelzer> which is ok as we mostly review one and then sub-check differences for the others
14:54 <sarnold> and multi-package reviews might be harder to organize
14:55 <slyon> right, like all the *-perl packages which we can squash into a single bug
14:55 <sarnold> we in the security team were working on prepping some metrics and just finding it hard to *count* how many mirs in what states we had..
14:55 <sarnold> iirc what we had to do launchpad scraping took an hour to execute every week
14:55 <slyon> but those are still handled individually, so having a separat bug for each of them should still be manageable
14:55 <cpaelzer> sarnold: and you tihnk counting would be better with this?
14:56 <cpaelzer> the scraping I mean
14:56 <sarnold> cpaelzer: well, it's hard to say; in the end we decided to scrap our launchpad scraping and move to jira, but, uh, we found earlier today that relying upon jira isn't without flaws too
14:56 <cpaelzer> this sounds like workflow optimization which is a thing
14:57 <cpaelzer> but most likely not our task or duty
14:57 <sarnold> perhaps, but it is something most of us touch
14:57 <sarnold> and making the things we touch often a bit nicer has rewards :)
14:57 <cpaelzer> there might be new work to describe and process workflows, which then I think would provide the stage to renew
14:57 <sarnold> whether or not this is nicer is another question
14:57 <cpaelzer> sarnold: I think it comes down to someone finding the time to make a POC on launchpad to show it
14:58 <sarnold> ah, good point. I hadn't considered that approach, heh
14:58 <cpaelzer> which I think starts with findin who did it in kernel
14:58 <cpaelzer> I guess it can all be LP API
14:58 <cpaelzer> when we consume a new MIR we'd run a tool which adds the stages
14:58 <cpaelzer> and then assign the review as one stage
14:59 <cpaelzer> I'm open to discuss/check such a POC but currently consider myself unable to create it
14:59 <cpaelzer> thanks for birnging the idea up though
14:59 <cpaelzer> it seems interesting indeed
14:59 <cpaelzer> having a hard stop now
14:59 <sarnold> thanks :D
14:59 <cpaelzer> any other other business?
14:59 <sarnold> that's it
14:59 <slyon> nope
14:59 <didrocks> nothing else
14:59 <cpaelzer> ok
14:59 <cpaelzer> then again
14:59 <cpaelzer> #endmeeting