(Really, that script should probably be moved to UCT, there's additional improvements I'd like to make to it that would be a little easier if it was in UCT and not in ubuntu-qa-tools.)
I guess what I'm more interested is how you see this being used in the signoff / tracking process. AFAICT, it cannot be used independently of changing the task state either acking or nacking it for the security pocket; it might be worth being possible change the assignee independently so that at the beginning of signoffs, you could change self-assign for kernels you're starting the sign-off process on, in part to indicate you're starting on them.
Apologies for the delayed review. I think the idea is okay; I should note that the kernel-sru-script that reports pending signoffs assigns the bug task to the person running the script as well (see https:/ /git.launchpad. net/ubuntu- qa-tools/ tree/security- tools/kernel- sru-check# n106 ) but only if the status is "Confirmed".
(Really, that script should probably be moved to UCT, there's additional improvements I'd like to make to it that would be a little easier if it was in UCT and not in ubuntu-qa-tools.)
I guess what I'm more interested is how you see this being used in the signoff / tracking process. AFAICT, it cannot be used independently of changing the task state either acking or nacking it for the security pocket; it might be worth being possible change the assignee independently so that at the beginning of signoffs, you could change self-assign for kernels you're starting the sign-off process on, in part to indicate you're starting on them.