[11:11] <seb128> cpaelzer, hey, I just saw bug #1912168. The proper process to suggest rls review for a team is usually to tag rls-<nn>-incoming and not directly target (especially without assignee)
[11:12] <cpaelzer> seb128: s/a team/some teams/ - e.g. these tags wouldn't mean anything for the server team
[11:12] <cpaelzer> seb128: good to know you follow the same as foundations
[11:12] <cpaelzer> seb128: have you added that already or should I?
[11:13] <seb128> cpaelzer, historically it was a workflow common to all 'distro' team, it's a suboptimal that server doesn't follow it ... do you guys have another way to flag issues for your team to consider?
[11:13] <cpaelzer> seb128: we triage all bugs of the packages we are susbcribed to
[11:13] <cpaelzer> no need to tag anything specially
[11:14] <seb128> well, sometime the importance is up for interpretation
[11:14] <seb128> there is still value imho in others being able to flag an issue they would like to propose for SRU or rls targetting
[11:14] <seb128> (as you just did there by adding the targetted lines)
[11:15] <cpaelzer> I added the tag to the case
[11:15] <cpaelzer> thanks for the discussion
[11:15] <seb128> thx, sorry I was about to type a reply to that
[11:16] <seb128> at least I leant that server was not follow the same process ;-)
[11:16] <cpaelzer> And in regard to our bug handling, if you add a tag or comment we will still see and think about it - all I'm saying is that our handling/triage isn't limited to those with a particular tag like this one
[11:17] <seb128> right
[11:19] <seb128> cpaelzer, glancing over the server section on http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-gg-incoming-bug-tasks.html there are a bunch of server ones that got tagged and not triaged, e.g https://bugs.launchpad.net/ubuntu/+source/drac/+bug/1897292 since septembre
[11:21] <cpaelzer> rbasak: we should later check how/why those slipped triage ^^
[11:22] <seb128> thx
[11:37] <seb128> was focal updated to the 5.8 kernel serie? (wondering due to bug 1910982)
[12:36] <rbasak> cpaelzer: I wouldn't consider those sorts of bugs within scope for our triage process anyway, though I don't know if that's the reason or if was something else.
[12:37] <rbasak> Also drac is in universe in Groovy?
[12:38] <rbasak> scope> because I'd consider work coming from FTBFS reports to be its own work item that gets prioritised as a whole, as opposed to handling piecemeal reports from bug reports that may or may not get filed
[12:38] <rbasak> s/FTBFS reports/the regular rebuild testing/
[14:47] <Laney> anyone else just get unsubscribed from the TB's list?
[14:49] <cjwatson> Yep, being discussed in ~is on MM
[14:50] <Laney> ok thanks, I'll assume I'm going to be put back :-)
[14:50] <cjwatson> Seems like the new CC got access to it and maybe thought it was meant to be a TB-members-only list or something?
[14:51] <Laney> ah yes, I got a couple of emails that explain more
[14:51] <Laney> seems like a bit of shoot first, ask questions later
[14:51] <cjwatson> Just a bit
[18:55] <marinelli> hi everyone
[18:57] <marinelli> how is it used by apt/aptitude the string passed with target release argument (eg: apt upgrade -s -t hirsute)
[18:59] <marinelli> I was having a look at the apt source code, but I was not able to find the way that argument is used
[19:01] <marinelli> I tried also with apt-cache, and it seems that something like `-t hirsute` is similar to `-t n=hirsute` instead of `-t a=hirsute`