| === cpaelzer__ is now known as cpaelzer | ||
| === mIk3_09 is now known as mIk3_08 | ||
| === didrocks999 is now known as didrocks | ||
| cpaelzer | o/ | 15:28 |
|---|---|---|
| didrocks | Happy Tuesday cpaelzer! | 15:28 |
| cpaelzer | to all of you as well :-) | 15:29 |
| cpaelzer | didrocks: doko: ddstreet: jamespage_: sarnold: pre-ping for MIR meeting | 15:29 |
| ddstreet | o/ | 15:30 |
| cpaelzer | #startmeeting Weekly Main Inclusion Requests status | 15:30 |
| meetingology | cpaelzer: Error: Can't start another meeting, one is in progress | 15:30 |
| sarnold | good morning | 15:30 |
| cpaelzer | hmm it tells me another meeting wasn't finished | 15:30 |
| * cpaelzer checks logs ... | 15:30 | |
| sarnold | #endmeeting | 15:30 |
| sarnold | rats | 15:30 |
| sarnold | nhaines: any chance you're around and can #endmeeting? | 15:31 |
| cpaelzer | only works for the owers I guess | 15:31 |
| doko | o/ | 15:32 |
| cpaelzer | #chair sarnold | 15:32 |
| cpaelzer | yeah all that would have to be in the control channel | 15:32 |
| cpaelzer | by former owner | 15:32 |
| cpaelzer | we have "[00:35] <nhaines> #endmeeting" but it seems it has not stopped | 15:33 |
| jamespage_ | o/ | 15:33 |
| cpaelzer | didrocks: doko: ddstreet: jamespage_: sarnold: does one of you mind if we go on (and fill their logs instead of ours) ? | 15:33 |
| jamespage_ | +1 | 15:33 |
| === jamespage_ is now known as jamespage | ||
| doko | go | 15:33 |
| sarnold | might as well keep going | 15:33 |
| ddstreet | +1 | 15:33 |
| didrocks | yep | 15:34 |
| cpaelzer | #topic current component mismatches | 15:34 |
| cpaelzer | #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg | 15:34 |
| cpaelzer | not too mcuh new in this one | 15:34 |
| cpaelzer | doko has set https://bugs.launchpad.net/ubuntu/+source/rpi-eeprom/+bug/1895137 back to New | 15:34 |
| ubottu | Launchpad bug 1895137 in rpi-eeprom (Ubuntu) "[MIR] rpi-eeprom; raspberrypi-userland" [Undecided,In progress] | 15:34 |
| cpaelzer | doko: on whom is this waiting now? | 15:34 |
| cpaelzer | you requested a bunch of things in https://bugs.launchpad.net/ubuntu/+source/rpi-eeprom/+bug/1895137/comments/13 | 15:35 |
| doko | us. fixes were uploaded without updating the report | 15:35 |
| doko | I'll look at this | 15:35 |
| cpaelzer | ok, so you'll do a re-review | 15:35 |
| cpaelzer | I'll assign it then to reflect that state | 15:35 |
| cpaelzer | of the rest I wanted to mention octavia | 15:36 |
| cpaelzer | https://bugs.launchpad.net/ubuntu/+source/octavia/+bug/1888309 | 15:36 |
| ubottu | Launchpad bug 1888309 in octavia (Ubuntu) "[MIR] octavia" [High,New] | 15:36 |
| cpaelzer | jamespage: this is on security atm - is this strictly needed this cycle to have things complete and working? | 15:36 |
| teward | #endmeeting | 15:36 |
| === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | <wxl> be nice | ||
| cpaelzer | ah teward had the power, thanks | 15:37 |
| teward | cpaelzer: anyone with a member cloak can +o here | 15:37 |
| cpaelzer | #startmeeting Weekly Main Inclusion Requests status | 15:37 |
| meetingology | cpaelzer: Error: Can't start another meeting, one is in progress | 15:37 |
| teward | and endmeeting | 15:37 |
| jamespage | cpaelzer: well it would be nice | 15:37 |
| teward | um... | 15:37 |
| teward | it's broke o.O | 15:37 |
| teward | #endmeeting | 15:37 |
| === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | <wxl> be nice | ||
| teward | #endmeeting | 15:37 |
| === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | <wxl> be nice | ||
| teward | o.O | 15:37 |
| cpaelzer | teward: nice try, but doesn't work :-) | 15:37 |
| teward | #startmeeting Weekly Main Inclusion Requests status | 15:37 |
| meetingology | teward: Error: Can't start another meeting, one is in progress | 15:37 |
| teward | i'll report to -irc and get meetingology punted | 15:37 |
| cpaelzer | sarnold: well then - how about any ETA forecast ? | 15:37 |
| cpaelzer | so that jamespage can plan accordingly | 15:37 |
| cpaelzer | sarnold: you can reply to that later | 15:38 |
| cpaelzer | while we wait on you asking the crystal ball | 15:38 |
| cpaelzer | let us go to the more busy | 15:38 |
| cpaelzer | #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg | 15:38 |
| didrocks | abseil is now ready to be reviewed and this is my next task | 15:38 |
| cpaelzer | thanks didrocks | 15:38 |
| cpaelzer | backuppc the server & security teams have agreed that this sadly won't be completed in time for hirsute | 15:39 |
| cpaelzer | so it will stay on 3.x and then complete in hopefulyl early 21.10 | 15:39 |
| cpaelzer | thereby it will stay in this view for a while | 15:39 |
| cpaelzer | other than that the one new (for me) thing is mtd-utils -> iniparser | 15:40 |
| cpaelzer | does that package mean anything to anyone here? | 15:40 |
| sarnold | cpaelzer: doko said he was going to take it in the last meeting | 15:41 |
| doko | yes, it's addressed in foundations | 15:42 |
| cpaelzer | it has no bug yet | 15:42 |
| cpaelzer | doko: would you later create a stub and assign it to whoever in foundations is on it? | 15:42 |
| cpaelzer | I'll consider silence to be "yes" :-) | 15:43 |
| cpaelzer | going on ... | 15:43 |
| sarnold | there's also a https://bugs.launchpad.net/ubuntu/+source/u-boot-menu/+bug/1907284 | 15:43 |
| ubottu | Launchpad bug 1907284 in u-boot-menu (Ubuntu) "[MIR] u-boot-menu" [Undecided,New] | 15:43 |
| sarnold | but it may be missing something, the white circle suggests there's no bug yet | 15:43 |
| cpaelzer | indeed sarnold | 15:43 |
| cpaelzer | that isn't new, it lacks the team subscriber | 15:43 |
| cpaelzer | without that it means "the reporter didn't shove it to us for review" | 15:44 |
| cpaelzer | but I guess that xnox didn't want to hold it back - as it otherwise looks ready | 15:44 |
| cpaelzer | I'll add the subscription for it to show up | 15:44 |
| sarnold | done | 15:44 |
| sarnold | I think :) ~ubuntu-mir ? | 15:44 |
| cpaelzer | thanks | 15:44 |
| cpaelzer | yes that works | 15:44 |
| cpaelzer | any volunteers for a review ? | 15:45 |
| cpaelzer | well it will come in the next section | 15:45 |
| cpaelzer | let us check if we have more there | 15:45 |
| cpaelzer | #topic New MIRs | 15:45 |
| cpaelzer | #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir | 15:45 |
| cpaelzer | the first (rpi-eeprom) was copy&pasta - fixed | 15:46 |
| cpaelzer | then we have left two | 15:46 |
| cpaelzer | https://bugs.launchpad.net/ubuntu/+source/u-boot-menu/+bug/1907284 | 15:46 |
| ubottu | Launchpad bug 1907284 in u-boot-menu (Ubuntu) "[MIR] u-boot-menu" [Undecided,New] | 15:46 |
| cpaelzer | as we just discussed | 15:46 |
| cpaelzer | and | 15:46 |
| cpaelzer | https://bugs.launchpad.net/ubuntu/+source/ledmon/+bug/1794219 | 15:46 |
| ubottu | Launchpad bug 1794219 in OEM Priority Project "[MIR] ledmon" [Medium,New] | 15:46 |
| cpaelzer | I have doen LEDmon in the past, might even be my first one | 15:47 |
| cpaelzer | my updates look so bad ... | 15:47 |
| cpaelzer | I'll re-review that one | 15:47 |
| sarnold | hehe :) | 15:47 |
| cpaelzer | anyone volunteering for u-boot-menu ? | 15:47 |
| * cpaelzer fetches a dice ... | 15:48 | |
| cpaelzer | really no one wants to, don't tell me everyone is busy - I know | 15:48 |
| ddstreet | i can take it | 15:48 |
| cpaelzer | awesome | 15:48 |
| cpaelzer | didrocks: also got one above | 15:48 |
| cpaelzer | so we get a fair spread it seems | 15:48 |
| cpaelzer | thanks ddstreet | 15:48 |
| cpaelzer | ok, the list is empty now | 15:49 |
| cpaelzer | next topic | 15:49 |
| cpaelzer | #topic Incomplete bugs / questions | 15:49 |
| cpaelzer | #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir | 15:49 |
| cpaelzer | we talked about needrestart last time | 15:49 |
| cpaelzer | new in this list is flashrom | 15:50 |
| cpaelzer | https://bugs.launchpad.net/ubuntu/+source/flashrom/+bug/1912371 | 15:50 |
| ubottu | Launchpad bug 1912371 in flashrom (Ubuntu) "[MIR] flashrom" [Undecided,Incomplete] | 15:50 |
| cpaelzer | On that I have already pinged mclemenceau | 15:50 |
| cpaelzer | If they want to own it they will update the bug accordingly | 15:50 |
| cpaelzer | if not someone has to make dependencies to disappear | 15:50 |
| cpaelzer | no action for the MIR team yet | 15:50 |
| cpaelzer | #topic Any other business? | 15:50 |
| cpaelzer | 10 minutes left, so what is up ? | 15:51 |
| didrocks | nothing for me | 15:51 |
| cpaelzer | anything MIR'ish or not worth to share/discuss right now? | 15:51 |
| * cpaelzer is out of topics and hot to re-enter some debugging | 15:51 | |
| didrocks | we might experiment with Wayland by default on the desktop. The latter is already in main, but we might have utilities entring main due to that | 15:51 |
| didrocks | but let’s see | 15:52 |
| didrocks | entering* | 15:52 |
| sarnold | nothing for me | 15:53 |
| cpaelzer | didrocks: for 21.04 or 21.10 ? | 15:53 |
| didrocks | for 21.04 | 15:54 |
| cpaelzer | uh, wow | 15:55 |
| cpaelzer | good to be aware of | 15:55 |
| cpaelzer | thankd didrocks | 15:55 |
| cpaelzer | nothing else it seems | 15:55 |
| cpaelzer | thank you everyone | 15:55 |
| sarnold | wow :) | 15:55 |
| cpaelzer | and see you next weeks with all the reviews we assigned being done | 15:55 |
| sarnold | thanks cpaelzer, all :) | 15:55 |
| didrocks | thanks cpaelzer, everyone :) | 15:55 |
| cpaelzer | fake #endmeeting | 15:55 |
| cpaelzer | the channel still waits to be freed by the current owner | 15:56 |
| sarnold | nhaines: sorry, it appears the bot is unhappy, probably it doesn't matter.. | 15:56 |
| teward | sarnold: nhaines: bot is unhappy, i've poked -ops-team and -irc about it | 15:56 |
| teward | someone has to punt the bot | 15:56 |
| jose | #endmeeting | 17:24 |
| === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | <wxl> be nice | ||
| teward | jose: we did that | 17:24 |
| teward | i did like 3 times won't let us start anew | 17:24 |
| jose | #startmeeting | 17:24 |
| meetingology | jose: Error: Can't start another meeting, one is in progress | 17:24 |
| teward | see? | 17:24 |
| teward | hence: punt it | 17:24 |
| jose | #startmeeting | 17:32 |
| meetingology | Meeting started at 17:32:01 UTC. The chair is jose. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 17:32 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 17:32 |
| jose | blah blah | 17:32 |
| jose | #endmeeting | 17:32 |
| === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | <wxl> be nice | ||
| meetingology | Meeting ended at 17:32:08 UTC. Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-01-26-17.32.moin.txt | 17:32 |
| jose | teward: see? it behaves | 17:32 |
| teward | well you DID punt it :P | 17:32 |
| teward | now it behaves | 17:32 |
| teward | *points at the join/parts log* | 17:32 |
| teward | jose: thanks for kicking it. | 17:32 |
| jose | np :) | 17:32 |
| rbasak | o/ | 19:55 |
| rbasak | Oh, -2 | 19:55 |
| sil2100 | o/ | 19:59 |
| cyphermox | o/ | 19:59 |
| cyphermox | #startmeeting Ubuntu Technical Board | 19:59 |
| meetingology | Meeting started at 19:59:52 UTC. The chair is cyphermox. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 19:59 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 19:59 |
| === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | <wxl> be nice | Ubuntu Technical Board Meeting | Current topic: | ||
| mdeslaur | o/ | 20:00 |
| cyphermox | #chair cyphermox rbasak | 20:00 |
| meetingology | Current chairs: cyphermox, rbasak | 20:00 |
| cyphermox | #topic Apologies | 20:00 |
| === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | <wxl> be nice | Ubuntu Technical Board Meeting | Current topic: Apologies | ||
| cyphermox | (none, as far as I know) | 20:00 |
| cyphermox | who's there today? | 20:00 |
| mdeslaur | me | 20:00 |
| cyphermox | I think we're quorate? | 20:00 |
| sil2100 | o/ | 20:01 |
| cyphermox | yup | 20:01 |
| cyphermox | ok, moving along | 20:01 |
| cyphermox | #topic Action review | 20:01 |
| === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | <wxl> be nice | Ubuntu Technical Board Meeting | Current topic: Action review | ||
| cyphermox | #subtopic ACTION: Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns. | 20:01 |
| mdeslaur | *crickets* | 20:02 |
| cyphermox | lol | 20:02 |
| cyphermox | carry? | 20:02 |
| mdeslaur | yeah, carry | 20:02 |
| cyphermox | zug zug | 20:02 |
| cyphermox | #subtopic ACTION: formal ratification of third party seeded snap security policy, depends on: | 20:02 |
| cyphermox | #subtopic ACTION: vorlon to circle around with store, snapcraft, et all, and revise the snap source revision policy to be more clear with regards to rebuildability and GPL compliance. | 20:03 |
| cyphermox | vorlon: ? | 20:03 |
| sil2100 | This is regarding the seeded snaps, right? | 20:04 |
| mdeslaur | doesn't look like he's here | 20:04 |
| cyphermox | sil2100: yeah, I think so | 20:04 |
| cyphermox | just giving him some time to respond, since he did chime in in #ubuntu-meeting-2 earlier | 20:05 |
| mdeslaur | oh! didn't notice | 20:06 |
| vorlon | cyphermox: sorry - yes, still carry over | 20:06 |
| cyphermox | and well, many action items are his, too | 20:06 |
| cyphermox | ack! | 20:06 |
| cyphermox | #subtopic ACTION: vorlon to reply to seeded snap upload permissions question on list | 20:06 |
| cyphermox | same? | 20:06 |
| vorlon | basically no movement on any of mine since the last meeting | 20:06 |
| cyphermox | ah, ok | 20:06 |
| vorlon | (there was a Canonical midcycle roadmap sprint in the middle) | 20:07 |
| cyphermox | #subtopic ACTION: xnox to start a draft summarizing the OEM archive portion of the meeting which vorlon, infinity, and mdeslaur will review, edit, and ratify before we move on to figuring out the next step ([2/3 subquorum required if one of us slacks, to avoid holding up the process]) | 20:07 |
| cyphermox | ack. | 20:07 |
| teward | *lurks TB meeting* | 20:07 |
| cyphermox | vorlon: do you know about xnox's? | 20:07 |
| vorlon | uh, what did we determine last meeting? were there any updates to this? since at least the reviewer portion is no longer accurate | 20:07 |
| mdeslaur | same for me, apologies, I was supposed to ping him about that | 20:07 |
| cyphermox | oh, right, sorry | 20:08 |
| cyphermox | the last action items are just that | 20:08 |
| cyphermox | #subtopic ACTION: mdeslaur to follow up with xnox about OEM archive documentation | 20:08 |
| cyphermox | #subtopic ACTION: mdeslaur to follow up on xnox's track clarification post to the list from 2020-08-12 | 20:08 |
| cyphermox | carrying those as well then | 20:08 |
| mdeslaur | carry forward both of mine, yes, thanks | 20:08 |
| cyphermox | should we reassign some things? would that help? | 20:08 |
| mdeslaur | oh if anyone wants one of mine, feel free to steal it ;) | 20:08 |
| vorlon | likewise ;) | 20:09 |
| cyphermox | haha | 20:09 |
| sil2100 | Would be nice to have that documented, since the only thing for this we have right now is https://wiki.ubuntu.com/MIRTeam/Exceptions/OEM | 20:09 |
| sil2100 | I can follow up with Dimitri if needed | 20:10 |
| sil2100 | So you can re-assign it to me, my first TB task! yay | 20:10 |
| mdeslaur | sil2100: thanks, I'd appreciate it | 20:10 |
| cyphermox | ok | 20:10 |
| cyphermox | #action sil2100 to follow up with xnox about OEM archive documentation | 20:11 |
| meetingology | ACTION: sil2100 to follow up with xnox about OEM archive documentation | 20:11 |
| cyphermox | carrying the rest, I'll clean up the wiki | 20:11 |
| cyphermox | #topic Other agenda items | 20:11 |
| cyphermox | There were none on the Agenda wiki page... | 20:11 |
| === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | <wxl> be nice | Ubuntu Technical Board Meeting | Current topic: Other agenda items | ||
| cyphermox | at least, as of half an hour ago when I prepared for the meeting | 20:12 |
| cyphermox | #topic Pending mailing list items | 20:12 |
| === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | <wxl> be nice | Ubuntu Technical Board Meeting | Current topic: Pending mailing list items | ||
| cyphermox | I don't know that any were definitely missed; but in case: | 20:12 |
| cyphermox | #subtopic Proposal for exception to existing fwupd SRU policy | 20:12 |
| rbasak | I don't think that request has been addressed yet. | 20:12 |
| vorlon | I haven't had a chance to digest that one yet fwiw, sorry | 20:12 |
| cyphermox | did anyone respond on this one from Mario? | 20:12 |
| cyphermox | ok | 20:12 |
| cyphermox | I'm inclined to consider that as standard hardware enablement? | 20:13 |
| rbasak | Though I think maybe it's one for the SRU team, not the TB? | 20:13 |
| vorlon | (at first blush, I am unenthusiastic about it) | 20:13 |
| rbasak | There didn't seem to be anything in that request not already covered by the TB's HWE delegation to the SRU team. | 20:13 |
| rbasak | (from memory) | 20:13 |
| cyphermox | aye | 20:13 |
| vorlon | rbasak: ah; I thought it went to the TB because you referred it there from the SRU team? | 20:13 |
| rbasak | No that was Thunderbird | 20:14 |
| vorlon | oh ok | 20:14 |
| rbasak | (that request involved deliberately breaking some packages, so I didn't think it fitted into the scope of the existing delegation) | 20:14 |
| cyphermox | to me, fwupd point the first seems like HWE | 20:15 |
| vorlon | does someone want to respond and kick it back to the SRU team then? | 20:15 |
| cyphermox | and fwupd point second sounds a lot like a standard SRU bugfix | 20:15 |
| cyphermox | I'll respond | 20:15 |
| vorlon | (fwiw, my concern about a blanket exception for fwupd is that this is a userspace daemon, not just code changes that directly related to hardware enablement, and there could be compatibility concerns) | 20:16 |
| cyphermox | sure | 20:16 |
| cyphermox | so you're going as letting the SRU team decide just this one, and then we think more about a stnading exception? | 20:16 |
| rbasak | Wearing my SRU hat, I'm not sure I buy the reason given for needing major upstream version bumps though. The justification seems to be a solution presupposing the problem. | 20:16 |
| cyphermox | I can't say I disagree with that, the method of doing the firmware updates via EFI wouldn't be subject to changing much | 20:17 |
| rbasak | The SRU team would grant a standing exception still though? | 20:17 |
| vorlon | if we're saying this is in the domain of the current SRU team delegation, how about we just respond on the list with the redirect and let the SRU team sort it out | 20:18 |
| rbasak | Since it's within the SRU team's remit to decide on a case-by-case basis. We (SRU team) reintroduced the "exception list" for consistency within ourselves only. | 20:18 |
| rbasak | +1 | 20:18 |
| cyphermox | #action cyphermox to respond to Mario's SRU exception request, this is handed back to the SRU team. | 20:18 |
| meetingology | ACTION: cyphermox to respond to Mario's SRU exception request, this is handed back to the SRU team. | 20:18 |
| cyphermox | that sounds right? | 20:18 |
| mdeslaur | +1 | 20:18 |
| cyphermox | #subtopic Updating thunderbird from 68 to 78 in focal | 20:18 |
| cyphermox | rbasak: you want to tell us more about the current state of this, as you've been most involved in the thread? | 20:19 |
| vorlon | I had some comments to make on that one regarding the specific rationale why replacing packages with dummy packages would/wouldn't be ok, but I have no concerns about the conclusion | 20:19 |
| mdeslaur | so the two packages are tinyjsd and jsunit, which AFAIK existed solely to be able to build enigmail | 20:19 |
| sil2100 | I guess the remaining thing to decide is what to do with tinyjsd and jsunit then, yes? i.e. if those should be turned to dummy packages? | 20:21 |
| rbasak | I believe the appropriate resolution has been agreed. We're just waiting on uploads. | 20:21 |
| mdeslaur | they don't currently work with firefox anymore, and they won't work with the newer thunderbird. I believe the new basically empty enigmail package no longer needs them either. | 20:21 |
| rbasak | I believe they're being turned into dummy packages - that was mdeslaur's proposal, and nobody objected. | 20:21 |
| cyphermox | ok | 20:22 |
| vorlon | I will still want to write things down on the list, but in case we want to ratify this during the meeting, my thought process is: 1) the thunderbird upgrade is reasonable and necessary for supportability reasons; 2) the reverse-dependencies would at best become uninstallable after the upgrade of thunderbird so having them converted to dummy packages doesn't have further negative impact on users, | 20:22 |
| vorlon | and does facilitate unattended upgrades; 3) if a user wants to keep these revdeps installed for some reason they would have to downgrade or pin thunderbird and if they're doing that anyway they can do the same for the revdep packages | 20:22 |
| mdeslaur | yes, I'm in agreement | 20:24 |
| cyphermox | +1 | 20:24 |
| sil2100 | +1 | 20:24 |
| rbasak | +1 | 20:24 |
| cyphermox | #agreed vorlon's thoughts on thunderbird process | 20:24 |
| meetingology | AGREED: vorlon's thoughts on thunderbird process | 20:24 |
| sil2100 | I like Robie's proposition to make sure to document this somewhere | 20:25 |
| cyphermox | yup | 20:25 |
| cyphermox | #subtopic Use of the TB mailing list | 20:25 |
| cyphermox | was there anything left to discuss on that one? | 20:25 |
| teward | *raises hand with CC hat on* | 20:25 |
| cyphermox | teward: hi! | 20:25 |
| teward | For my understanding, I'd like the TB to specifically determine the intent of the use of the TB list, and in turn if necessary update the description documentation on it to indicate it's a public or private list. | 20:26 |
| teward | Given the recent... I'll call it 'chaos'... with the change of rights, viewability, etc. by Jose on this, I'd like to make a note that the TB should make a decision on this, and accordignyl update the description to indicate whether it's public or member-only/internal-only | 20:26 |
| cyphermox | I think what we're missing now is basically updating the "About technical-board" section for the ML to make sure things are clear | 20:27 |
| teward | just a minor thing but I'd like to bring that up since you indicated "use of the mailing list" and I"ve had ${TONS_OF_STUFF} to not track the discussion outside of me bringing it up to the CC ;) | 20:27 |
| rbasak | Oh | 20:27 |
| teward | cyphermox: then as soon as that's updated, I won't have a reason to complain :0 | 20:27 |
| rbasak | I did have a proposal for basically that that remains outstanding on the list. | 20:27 |
| cyphermox | ok | 20:28 |
| rbasak | https://lists.ubuntu.com/archives/technical-board/2021-January/002532.html | 20:28 |
| vorlon | AIUI no members of the tb are still administrators of the mailing list and cannot update the description? | 20:28 |
| mdeslaur | +1 on rbasak's proposal | 20:28 |
| teward | vorlon: CC has admin | 20:28 |
| rbasak | I like Robie's proposition to make sure to document this somewhere> Should we require this then, in approving the Thunderbird request? | 20:28 |
| teward | you choose wording, we'll toss it up | 20:28 |
| vorlon | teward: ok | 20:28 |
| teward | (I was in it yesterday in 'read only' mode, you can consider me PoC for this one) | 20:28 |
| teward | (if you need a dedicated PoC) | 20:28 |
| teward | ("read only" meaning I was looking @ settings but not tweaking ;) ) | 20:29 |
| cyphermox | rbasak: your proposal for the ML was straight up agreeing to the wording, correct? | 20:29 |
| rbasak | cyphermox: correct | 20:29 |
| rbasak | Just the wording change, which also means that nothing else changes. | 20:29 |
| cyphermox | I'm +1 on your wording. | 20:30 |
| sil2100 | +1 | 20:30 |
| vorlon | +1 | 20:31 |
| rbasak | Thanks! | 20:31 |
| teward | vorlon: that brings another question you guys can handle internally, or bring up for CC to mull over: does TB *want* list admin, while keeping CC as a fallback admin in case we run into another case of TB Not Being Admins (i.e. what we had before we went through IS and such to give CC admin) | 20:31 |
| rbasak | Action to teward then please? | 20:31 |
| cyphermox | #agreed Make use of rbasak's copy suggestion for updating the mailing list's "About" section. | 20:31 |
| meetingology | AGREED: Make use of rbasak's copy suggestion for updating the mailing list's "About" section. | 20:31 |
| teward | #action teward / community council to update TB mailing list "About" section with agreed upon wording | 20:31 |
| meetingology | ACTION: teward / community council to update TB mailing list "About" section with agreed upon wording | 20:31 |
| rbasak | Thank you! | 20:31 |
| cyphermox | ahah, I was just typing that | 20:31 |
| teward | cyphermox: i was already ahead of you ;) | 20:32 |
| teward | sorry :) | 20:32 |
| teward | (i know i'm not chair and asserted it with op but xD) | 20:32 |
| rbasak | Interesting to know that works | 20:32 |
| cyphermox | teward: I don't feel like it's likely we'd need admin all that much | 20:32 |
| cyphermox | since we do have moderation | 20:32 |
| teward | cyphermox: ack, works for me, less people with the admin password the better | 20:32 |
| rbasak | I'm happy with it as is. We can change things if something comes up. | 20:32 |
| teward | (in terms of security) | 20:32 |
| vorlon | teward: I expect TB should handle the list moderation internally, and that's the only administrative function I've ever needed to touch in N years | 20:32 |
| teward | vorlon: that's what I'd expect | 20:33 |
| vorlon | I would just not like the CC making config changes without consulting the TB :) | 20:33 |
| rbasak | Before we continue, I have one question above on the Thunderbird exception please | 20:33 |
| cyphermox | #agreed TB does not need admin access to the ML at this point in time | 20:33 |
| meetingology | AGREED: TB does not need admin access to the ML at this point in time | 20:33 |
| cyphermox | rbasak: yes, I just wanted to conclude one topic at a time | 20:33 |
| rbasak | Sure | 20:33 |
| cyphermox | #subtopic Back on thunderbird | 20:33 |
| teward | vorlon: that's a given as well, we wouldn't touch anything unless either ERR:CRITICAL or ERR:TBConsulted | 20:33 |
| rbasak | So from above, for clarity | 20:34 |
| cyphermox | rbasak: you were asking about whether we'd require the write-up? | 20:34 |
| rbasak | I like Robie's proposition to make sure to document this somewhere> Should we require this then, in approving the Thunderbird request? | 20:34 |
| rbasak | Right | 20:34 |
| rbasak | I would like a bit of a cultural shift in Ubuntu in this regard. | 20:34 |
| rbasak | Of everyone doing a better job of writing up user-impacting changes. | 20:34 |
| cyphermox | what form would that take though? | 20:35 |
| cyphermox | things are often documented by way of mailing list, for better or for worse :) | 20:35 |
| rbasak | I don't really mind what form, as long as it's a noise-free single summarised and linkable explanation. | 20:35 |
| rbasak | I wouldn't want to mandate anything specific either, really. | 20:35 |
| cyphermox | I think this is just that think that probably belongs to devel or devel-announce? | 20:36 |
| sil2100 | Yeah, one or both even | 20:36 |
| rbasak | But for example if it's a decision scattered amongst multiple bug comments or an ML thread, then when confusion arises in the wider community, I can't resolve it with a single authoritative link that community members can be expected to read | 20:36 |
| cyphermox | indeed | 20:36 |
| cyphermox | also, release notes | 20:37 |
| sil2100 | Well, release notes are fine when we're doing point-releases or releases | 20:37 |
| rbasak | So I want to push as little as necessary, and just say what I want to make better, rather than dictate how it is to be done | 20:37 |
| sil2100 | But for changes in stable series before a release is happening - we don't have a good place for that right now | 20:37 |
| teward | as a community member (not my CC hat!) I would agree with better Release Notes and such | 20:37 |
| teward | for ongoing SRU changes I'm not sure that's necessary unless there's some form of Major Breaking Change not handled in the considerations | 20:37 |
| sil2100 | So for instance for .2 it makes sense to document it in the release notes | 20:38 |
| cyphermox | sil2100: that arguably should show up in Changes doc for a stable release; but in the meantime a mailing list suffices | 20:38 |
| sil2100 | But inbetween .2 and .3, it's a bit confisuing if we put it there before release | 20:38 |
| cyphermox | I see we're in full agreement | 20:38 |
| rbasak | The release notes for .2, written up before the change hits -updates, would be fine by me, because it meets my requirements - an authoritative summary that can be linked to. | 20:38 |
| cyphermox | well, the Changes/ Release notes could still just point to the mailing list post | 20:38 |
| rbasak | So would a -devel or -devel-announce ML post | 20:38 |
| rbasak | Pointing to an ML post would be fine by me, providing there's a noise-free summary there, and not a noisy thread to read through | 20:39 |
| cyphermox | "XYZ changed, causes FGH to be broken, see <link> for full rationale" | 20:39 |
| cyphermox | nah | 20:39 |
| cyphermox | does -devel / -devel-announce post sound fine for everyone to document this, and who will respond on the thread? | 20:40 |
| cyphermox | (I'm +1) | 20:41 |
| rbasak | A question for everyone first. Do you want to mandate a specific method? Because I don't. | 20:41 |
| cyphermox | nah, I'd just recommend it as part of "please write documentation for this change" | 20:41 |
| sil2100 | Maybe mandating a specific method wouldn't be the best thing, but recommending sending an e-mail to devel/devel-announce would be nice | 20:41 |
| rbasak | Recommend instead of mandate is good. | 20:41 |
| sil2100 | Since it's then easier to get all the interesting stuff from single place to put on the release notes | 20:42 |
| rbasak | So is everyone suggesting recommendations here, and not a mandate? | 20:42 |
| cyphermox | MUST document, MAY use established mailing lists -devel or -devel-announce | 20:42 |
| sil2100 | +1 | 20:42 |
| rbasak | +1 | 20:43 |
| cyphermox | apologies for using RFC parlance | 20:43 |
| rbasak | The clarity is good :) | 20:43 |
| cyphermox | mdeslaur, vorlon ? | 20:44 |
| mdeslaur | 0 | 20:44 |
| cyphermox | ok | 20:44 |
| vorlon | what is the full scope of this proposed MUST... and where is the documentation requirement to be documented? | 20:44 |
| cyphermox | that's a good point, this should go with an update of what we're expecting, say, on the wiki | 20:45 |
| rbasak | I want a good faith attempt at summarising the decision, the rationale, known downsides, and any available workarounds for users affected by downsides. | 20:45 |
| rbasak | (as at attempt at defining it) | 20:45 |
| vorlon | so this is for SRU changes | 20:45 |
| vorlon | ? | 20:45 |
| vorlon | any reason not to have this dealt with internal to the SRU team? | 20:46 |
| rbasak | Those are general requirements that I think we can choose to apply to any decision we're asked to make. | 20:46 |
| rbasak | And, if we want, recommend that other teams do the same. | 20:46 |
| cyphermox | SRU justification is normally documented on bug reports though | 20:46 |
| vorlon | ok, for TB decisions? | 20:46 |
| teward | vorlon: i'd say it also extends to Security changes (my 2 cents as a community member and dev person) but the Security team does a good job with USNs on those cases where it'll be known to break something | 20:46 |
| vorlon | the existing wiki structure is currently suboptimal | 20:46 |
| rbasak | Yes, for TB decisions would be a start. | 20:46 |
| teward | as "Known Potential Regressions" ;) | 20:47 |
| rbasak | It's something that I'd like to change culturally across the project, and so leading from the TB seems like a good idea to me. | 20:47 |
| vorlon | it can be very difficult to locate historical TB decisions because basically all we have is an index of TB meeting logs | 20:47 |
| teward | vorlon: i have a question for you on that | 20:47 |
| vorlon | are we going to commit to keeping a directory of decisions in the wiki? | 20:47 |
| cyphermox | that's why we were supposed to have the TeamReports, I think | 20:47 |
| teward | have you considered asking IS to create a Discourse section for you to drop all the decisions as independent threads there? | 20:47 |
| vorlon | (mailing lists definitely don't help with the "locate past decisions" problem) | 20:48 |
| cyphermox | well, perhaps that doesn't quite make it easier to find | 20:48 |
| teward | asking primarily because the CC has moved most of our stuff to a Discourse section for that, but it could get chaotic to dig deeper for other things. | 20:48 |
| teward | (permissions, etc. as Discourse isn't... kind... with perms) | 20:48 |
| rbasak | (leading by example, that is, not mandating things on other teams since I wouldn't want to accidentally force the documentation of minutae. | 20:48 |
| vorlon | I had not considered that because I don't see the advantages of Discourse over the wiki for things that would not be discussions :) | 20:48 |
| rbasak | ) | 20:48 |
| rbasak | directory> yes, that works. Very easy if we're going to have linkable decisions. | 20:48 |
| teward | vorlon: ack, just thought I'd ask since we're all on it (though I'm not TB) | 20:48 |
| cyphermox | this is quite a few different work items | 20:49 |
| cyphermox | so do we agree to start documenting by example? | 20:49 |
| rbasak | I'm not sure "documenting by example" is exactly what we just discussed. Let me see if I can summarise... | 20:50 |
| cyphermox | it's only part of it | 20:50 |
| mdeslaur | I don't quite understand...so if I update jsunit, and it breaks...the first place I would look is the changelog, and then I'd go to the bug number listed...I definitely wouldn't comb through a wiki to figure it out | 20:50 |
| rbasak | 1) Start requiring, on a decision-by-decision basis, summary documentation of decisions, where the documentation required would be "a good faith attempt at summarising the decision, the rationale, known downsides, a | 20:51 |
| rbasak | nd any available workarounds for users affected by downsides" | 20:51 |
| rbasak | 2) Recommend, but not require, somewhere specific for this | 20:51 |
| rbasak | 3) Operate a directory somewhere of these summaries | 20:51 |
| cyphermox | sounds to me more and more like bugs are the right place to have all this | 20:52 |
| rbasak | mdeslaur: I wouldn't expect you to comb through the wiki. I'd expect there to be a link to a summary, which would be discoverable from the bug. | 20:52 |
| rbasak | Or if you want to place a summary in a bug comment, I'm fine with that too, since it's linkable. But it should be an actual linkable self-contained bug comment, not a general "read through all the noise in the bug to figure out what happened". | 20:53 |
| rbasak | In my enumerated list above, I only really care about 1, FWIW. The other two were suggested additions, AIUI. | 20:53 |
| cyphermox | I'm not sure how to handle all of this; I think everyone is in agreement that we need things that come up to the TB well documented, but I don't know how to distill this into the actionable | 20:55 |
| rbasak | To be clear, by "decision-by-decision basis" I mean "for decision A, please document; for decision B, no need" | 20:55 |
| cyphermox | like, actions for the right now, this particular request (Thunderbird updates) | 20:55 |
| sil2100 | I'm thinking of it more in the terms: informing users and developers of upcoming big changes so that it is not a shock to at least some when they notice something not working | 20:55 |
| sil2100 | This is why I liked the idea of simply following up with an e-mail to devel or devel-announce | 20:56 |
| rbasak | sil2100: also, retrospective explanations. "My system's broken; what's going on and how dare you do this?" -> "This is what we did and why". | 20:56 |
| rbasak | Another point of clarity: I'd expect the person driving the change, not the TB, to write the summary. Generally that's the best person to do it, IMHO. I just want a good faith effort, without any requirement for a draft to be approved or anything. | 20:57 |
| cyphermox | perhaps there's two different things; rbasak, would you write up your proposal for the long-term, on the TB mailing list, for what how you'd like us to proceed | 20:57 |
| rbasak | cyphermox: sure | 20:57 |
| mdeslaur | so send an email to devel or devel announce that contains a summary documentation of the change, file a bug, link the email to the bug, then include the bug number in the update? | 20:57 |
| cyphermox | and in parallel we can address just the thunderbird case right now, (and how do we do so?) | 20:58 |
| cyphermox | mdeslaur: +1 | 20:58 |
| rbasak | Personally, I don't even care to require the linking. That can be done any time afterwards if it comes up. | 20:58 |
| cyphermox | rbasak: changelog should include all you need to understand the decision, for developers | 20:59 |
| rbasak | (I'd prefer to keep the requirements down and the proposal to be simple) | 20:59 |
| cyphermox | rbasak: but users are not developers and are unliekly to look at changelog | 20:59 |
| rbasak | I think we're bikeshedding this too much. | 20:59 |
| cyphermox | I don't know that we are -- there's competing requirements | 21:00 |
| rbasak | Can we just agree that we'd like a documentation summary, and leave the rest? | 21:00 |
| cyphermox | it needs to be written somewhere, but if there is already a SRU in progress won't we already have everything there? | 21:00 |
| rbasak | This doesn't need to be perfect; just a start. | 21:00 |
| rbasak | competing requirements> IMHO, you're all adding requirements when there's no need. | 21:01 |
| cyphermox | you want the decision to be written down somewhere, that's understood | 21:01 |
| rbasak | It'd be an improvement just to ask that a summary exists somewhere. There's value there immediately because it can be linked to in the future. | 21:01 |
| cyphermox | AFAIK the only thing that goes with that is that this summary needs to be findable somewhere in 6 months | 21:02 |
| rbasak | How it's linked or where it goes could be decided later. Maybe let people do what they like and see what works the best. | 21:02 |
| cyphermox | leave it to the developers for now and we can copy-paste as needed? | 21:02 |
| rbasak | +12 | 21:03 |
| cyphermox | that works | 21:03 |
| cyphermox | agreement? | 21:03 |
| sil2100 | Apologies everyone but I have to go AFK now o/ | 21:03 |
| sil2100 | But seems fine for me | 21:03 |
| cyphermox | #action rbasak to write up proposal for how to do decision documentation for the future | 21:04 |
| meetingology | ACTION: rbasak to write up proposal for how to do decision documentation for the future | 21:04 |
| mdeslaur | +1 on requesting a summary | 21:04 |
| cyphermox | alrighty | 21:04 |
| cyphermox | #agreed thunderbird changes should include a summary of the decisions / changes written somewhere; left at the discretion of the developers | 21:04 |
| meetingology | AGREED: thunderbird changes should include a summary of the decisions / changes written somewhere; left at the discretion of the developers | 21:04 |
| cyphermox | (I mean this paritcular request, to be clear) | 21:05 |
| cyphermox | #topic Community bugs | 21:05 |
| === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | <wxl> be nice | Ubuntu Technical Board Meeting | Current topic: Community bugs | ||
| cyphermox | "There are currently no open bugs." | 21:05 |
| cyphermox | I'm moving along fastish, because I'm also busy with other things, but please chime in if I'm going too fast | 21:05 |
| cyphermox | #topic Chair for next meeting | 21:06 |
| === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | <wxl> be nice | Ubuntu Technical Board Meeting | Current topic: Chair for next meeting | ||
| teward | *is waiting for AOB for a semi-big issue* | 21:06 |
| cyphermox | I think this ends up being rbasak's turn, with vorlon as backup. | 21:06 |
| cyphermox | ah? | 21:06 |
| vorlon | fast> fine by me, we're over time :) | 21:06 |
| cyphermox | teward: if it's big enough, would it be better written in the ML? | 21:06 |
| cyphermox | or do you think it needs to be addressed now, since we're indeed over time? :) | 21:07 |
| teward | cyphermox: if and only if TB prioritizes the investigation on it, yes. I'll give a cliffs notes FYI: it's about the HWE kernels, Desktop force-auto-updating to HWE, and the recentt storm of [CENSORED] that it's causing to end users. | 21:07 |
| rbasak | I agree with teward that it is rather urgent. | 21:07 |
| teward | but to put it bluntly: something that was decided in 20.04 cycle was desktops *automatically* install HWE kernels when available. By default. As a result, with the 5.8 kernel migration we see MAJOR breakage | 21:07 |
| teward | kernel panics in VBox drivers, hardware drivers for networking going AWOL/fubar, etc. | 21:08 |
| teward | according to sarnold there's Foundations / Desktop / Kernel at fault | 21:08 |
| teward | according to rbasak it's Desktop partly at fault for the original decision | 21:08 |
| sarnold | more like, I'm not sure who exactly made that decision :) | 21:08 |
| teward | and according to me it's *everyone* at fault | 21:08 |
| teward | so I'd like the TB to spearhead a top-down approach of poking around at this - determine: | 21:09 |
| rbasak | Well hold on, I didn't say fault | 21:09 |
| cyphermox | I'm not fond of assigning fault, tbh, though a post-mortem of a failure is beneficial | 21:09 |
| teward | rbasak: well i'm half-summarizing it :P | 21:09 |
| teward | i'd like TB to post-mortem this | 21:09 |
| teward | and poke and see what broke, where, and how this can be averted in the future | 21:09 |
| rbasak | I would expect the desktop team to lead for what is primarily a desktop regression, that's all. | 21:09 |
| vorlon | fwiw there was an internal meeting this morning to discuss the lack of communication of this new behavior, which will be addressed | 21:09 |
| mdeslaur | TIL we're automatically installing HWE stuff | 21:09 |
| teward | ^ this | 21:09 |
| vorlon | and the kernel team has also done an internal post-mortem regarding the breakage due to CI gaps and is working to resolve the regressions | 21:10 |
| rbasak | I see there being two parts to this. | 21:10 |
| cyphermox | so are we expecting a statement from the TB about this? | 21:10 |
| rbasak | 1) the new behaviour | 21:10 |
| rbasak | 2) the regressions | 21:10 |
| cyphermox | or a summary of what happened and how it can be avoided in the future | 21:10 |
| teward | cyphermox: TB spearhead poking the relevant teams to do postmortem analysis, and then given the responses summarize what happened and how this will be avoided going forward | 21:10 |
| teward | from sarnold i was told there was an autopkgtest problem where dkms stuff wasn't autopkgtested with HWE enabled was put into place | 21:10 |
| teward | but that's second-hand knowledge | 21:11 |
| teward | (this does NOT have me with my CC hat by the way, but as a concerned member of the community) | 21:11 |
| teward | severely concerned* | 21:11 |
| rbasak | I'd like communication about what is going on with both. It's hard to understand the regressions without knowing that the behaviour change happened at all, and also without knowing the rationale/trade-offs in that decision. | 21:11 |
| sarnold | this change has a bullet point in the release notes https://wiki.ubuntu.com/FocalFossa/ReleaseNotes#Ubuntu_Desktop "Ubuntu Desktop flavour now always tracks HWE kernel (hardware enablement). It means that from around the time of the 20.04.2 release Ubuntu Desktop will gain new major kernel versions every 6 months through to summer of 2022, even if you installed Ubuntu earlier than this. " | 21:11 |
| cyphermox | I think there may be a few discussions that might happen internal to Canonical to discuss these things, who'd be in the best position to make the relevant bits known to the community? | 21:11 |
| sarnold | the fact that the hwe was released before the .2 release *also* surprised a lot of people | 21:11 |
| teward | ^ which in turn has lead to a HUGE number of Ask Ubuntu "It's broken after kernel update!" for drivers, software, etc. | 21:12 |
| * sil2100 still semi-around | 21:12 | |
| cyphermox | or at least we'll need somebody to lead putting things together | 21:12 |
| cyphermox | and chasing people for answers | 21:12 |
| rbasak | And then for the regressions, I'd like communication about what issues are understood/root caused, and what users can expect for those - which means that users and the community can understand if their specific issues are known, or still need reporting. | 21:12 |
| cyphermox | teward: it's big enough perhaps a ML post would help | 21:13 |
| cyphermox | I'm getting lost in it all | 21:13 |
| vorlon | sarnold: before> this may be surprising, but it's not a change; the hwe kernel is always updated before the point release, it just wasn't consequential at .2 before now because there wasn't release media selecting hwe | 21:13 |
| teward | cyphermox: welcome to me when I was first responding to this saying "WHUT>>>?" | 21:13 |
| sarnold | vorlon: ah, thanks | 21:13 |
| vorlon | sarnold: it's self-evident that the hwe kernel updates must be released at least /some/ time before the point release, in order to master media | 21:13 |
| cyphermox | teward: yep. | 21:13 |
| sarnold | vorlon: but them being installed on to existing users before that .2 is out is surprising and new this time around | 21:14 |
| vorlon | yes | 21:14 |
| rbasak | What I'd like, and what I think we're missing right now, is for someone to "take point" and take responsibility for the issues. | 21:17 |
| rbasak | Right now, every time this comes up, plenty of people opine and clarify what happened, but nobody will take responsibility or commit to anything. | 21:18 |
| rbasak | From an Ubuntu governance perspective, I don't think that's acceptable. | 21:18 |
| teward | and from my CC perspective, I don't find it acceptable nobody's come forward with *any* information about the core cause, etc. | 21:18 |
| cyphermox | rbasak: do you want to take point? | 21:19 |
| teward | though i'm not petitioning as a CC member, it's just irking me because it's a Community problem if nobody comes around and either clams/handles | 21:19 |
| rbasak | Given the severity of the regressions, wider communication should have happened by now. And the reason it hasn't, AFAICT, is because everybody is, publicly at least, shirking responsibility. | 21:19 |
| rbasak | cyphermox: I'm not in a position to do that I don't think. It's down to the uploaders involved, or anybody they want to delegate to. | 21:19 |
| cyphermox | someone will need to chase people to ask them for post-mortem information, and someone will need to collate that information from multiple source to make that just one easy to understand case | 21:20 |
| sil2100 | This was indeed a huge miss and it's really really unfortunate that we missed communicating this - we have action items in the release team to document the current situation and follow up on this | 21:20 |
| cyphermox | so the release team already has that on their radar? | 21:20 |
| vorlon | rbasak: please clarify what form you believe "taking responsibility" should take in this regard. As I said, the kernel team is actively working on resolving the known regressions | 21:21 |
| sil2100 | cyphermox: yes, we have action items regarding communication, changing the documentation and release notes, everything assigned to be done before .2 is out | 21:21 |
| sil2100 | And the kernel team, as mentioned by vorlon, is actively working on the introduced regressions | 21:22 |
| rbasak | vorlon: I'm unable to answer fully because there's been no communication. So communicating would be a start, and I gave some specifics on that above. With that communication I'd be in a position to opine further, but for now, it's the lack of communication that's the biggest issue for the community, IMHO. | 21:22 |
| vorlon | rbasak: communicating what, where, to whom? We have actions from the previous meeting to post to ubuntu-devel (xnox), make an announcement on discourse (bdmurray), and follow up on https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1911614 (bdmurray) | 21:23 |
| ubottu | Launchpad bug 1911614 in ubuntu-meta (Ubuntu) "Ubuntu 20.04 and 20.04.1 images use linux-generic-hwe-20.04 instead of linux-generic" [Undecided,Confirmed] | 21:23 |
| rbasak | vorlon: I think I covered that above? | 21:24 |
| rbasak | To whom> to the community. Like before, I don't care where, as long as it can be linked to. | 21:25 |
| cyphermox | rbasak: teward: are the bug, a future post to ubuntu-devel and discourse addressing your concerns? | 21:25 |
| cyphermox | this does communicate things to the community, in various methods | 21:25 |
| teward | cyphermox: yes, provided that's done within $ReasonableTimeFrame (~2 weeks at most) because I don't want to have to go back to the community in 2 weeks time with people still complaining and have to say "Listen, we need a postmortem on this and information made publicly." | 21:25 |
| cyphermox | there's alreday the bug description that looks okay enough to me to describe what happened | 21:26 |
| teward | this said, I'd like TB and Desktop (or Foundations) to sit together and discuss this new change of pushing HWE on 20.04 and 20.04.1 install image users | 21:26 |
| sil2100 | As for taking responsibility - we, the release team, will take responsibility for that as we should have made sure it's communicated in the first place IMO | 21:26 |
| teward | because that's... a LOT more problematic now | 21:26 |
| rbasak | If this happens timely, then yes - let's see what's communicated though. I think I've expressed above what I'd like on that. | 21:26 |
| rbasak | Thanks sil2100 | 21:26 |
| cyphermox | okay | 21:26 |
| cyphermox | so here it is | 21:26 |
| sil2100 | rbasak, teward: as mentioned, the current plan is to get the communication+documentation sorted out before .2 is out, so till next week | 21:27 |
| * mdeslaur -> eod | 21:27 | |
| cyphermox | #action cyphermox to pester the release team before next meeting about documentation for the HWE changes in focal. | 21:27 |
| meetingology | ACTION: cyphermox to pester the release team before next meeting about documentation for the HWE changes in focal. | 21:27 |
| cyphermox | the next meeting is in two weeks, we'd want something before then, I agree | 21:27 |
| cyphermox | as to when, if people already know to make such announcements/documentation, I'm inclined to let them work. | 21:27 |
| cyphermox | (as above, as long as it doesn't end up taking multi-months) | 21:28 |
| cyphermox | am I missing something? | 21:28 |
| teward | nope | 21:28 |
| cyphermox | cool | 21:29 |
| cyphermox | #endmeeting | 21:29 |
| === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | <wxl> be nice | ||
| teward | but I'd like TB and Desktop/Release to discuss specifically how to prevent this kind of chaotic evil going forward - the forced-HWE for 20.04 and 20.04.1 installs seems like a Major CHange, and going forward this needs to be... addressed... | 21:29 |
| teward | in a way that won't kill everything | 21:29 |
| teward | that's all :) | 21:29 |
| teward | sil2100: if you dont' mind pinging me when that notie is made that'd eb great. | 21:29 |
| teward | s/notie/notice/ | 21:29 |
| sil2100 | o/ | 21:29 |
| cyphermox | changes sometimes happen; it's not out of malice | 21:29 |
| sil2100 | Suar | 21:29 |
| rbasak | Thanks cyphermox! | 21:30 |
| teward | cyphermox: no, but the community at large starts chastising Canonical and "Developers" for the problems ;) | 21:30 |
| sil2100 | Yeah, it's very VERY unfortunate that this miscommunication happened | 21:30 |
| teward | and from the CC perspective that's Bad ;) | 21:30 |
| cyphermox | but I agree things this big need to be well documented ahead of time | 21:30 |
| teward | +1 | 21:30 |
| cyphermox | (and even if we do, it's not going to be read...) | 21:30 |
| teward | cyphermox: better to have the documentation than not | 21:30 |
| cyphermox | yup | 21:30 |
| teward | in case someone like me is hunting and comes around as a support person on Ask Ubuntu and can (1) fill myself in on the process, and (2) I can explain to end users what happened in Plain Speak | 21:31 |
| teward | and they don't have to go around with metaphorical "murderous intent" about Ubuntu being "bad" | 21:31 |
| cyphermox | heh | 21:32 |
| vorlon | thanks, all! long meeting, but very productive | 21:32 |
| teward | yep sorry for adding an extra 30 minutes :P | 21:32 |
| vorlon | teward: "chaotic evil" - while I think it's entirely appropriate to have a review of the decision with the TB for any decision taken that results in disruption to our users, the decision wasn't taken lightly or with the intent of letting users regress | 21:40 |
| teward | vorlon: never said that was the case | 21:41 |
| teward | only that in *this* case the level and number of regressions brought it to a bit more of a 'chaotic' level | 21:41 |
| vorlon | ok. I read "chaotic evil" differently :) | 21:41 |
| vorlon | because "evil" implies intent | 21:41 |
| teward | vorlon: i'm usually vague sometimes, it keeps people wondering whether i'm ITSecurity levels of Insane | 21:41 |
| teward | vorlon: well from the end user perspective this is "chaotic evil" - no descriptions as to WHY this happened | 21:42 |
| teward | from my tech perspective it's more "the users think this is chaotic" and that the regressions are evil | 21:42 |
| teward | but no ill intent with the decision was meant | 21:42 |
| teward | from MY perspecgive, I just want an announcement made, and want someone to postmortem the issue | 21:42 |
| teward | and going forward figure a way to do the chagnes and keep it so this kind of chaos doesn't happen again | 21:43 |
| teward | tired of having to close 25 of the same thread as dupes of the same problem on Ask Ubuntu ;) | 21:43 |
| teward | vorlon: that said, Kernel Team perspective, you've all got a VBox regression and kernel panic | 21:43 |
| teward | not sure if you or anyone else saw my poke in -kernel | 21:43 |
| rbasak | I think maybe Thomas meant evil as in "necessary evil"? | 21:44 |
| teward | ^ yes | 21:44 |
| rbasak | I've been keeping a list | 21:44 |
| rbasak | I think there's a virtualbox dkms regression, an nvidia dkms regression (now fixed), and I've seen some references to a few other unclear things. | 21:45 |
| teward | though as i said to cyphermox and sarnold privately, "The Community" of users automatically blame everything broken as a dark mark or an intent of "Why are the Developers doing this to us?" evil assignment | 21:45 |
| sarnold | broadcom | 21:45 |
| rbasak | ^ agreed - hence my request to get decisions/rationale/trade-offs/downsides/workarounds documented better. | 21:45 |
| teward | vs. those of us in the know who know Regressions Happen but the users don't see 'fast enoug hfixes' for daily driver systems :) | 21:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
