19:59 #startmeeting Ubuntu Technical Board 19:59 Meeting started at 19:59:52 UTC. The chair is cyphermox. Information about MeetBot at https://wiki.ubuntu.com/meetingology 19:59 Available commands: action, commands, idea, info, link, nick 20:00 o/ 20:00 #chair cyphermox rbasak 20:00 Current chairs: cyphermox, rbasak 20:00 #topic Apologies 20:00 (none, as far as I know) 20:00 who's there today? 20:00 me 20:00 I think we're quorate? 20:01 o/ 20:01 yup 20:01 ok, moving along 20:01 #topic Action review 20:01 #subtopic ACTION: Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns. 20:02 *crickets* 20:02 lol 20:02 carry? 20:02 yeah, carry 20:02 zug zug 20:02 #subtopic ACTION: formal ratification of third party seeded snap security policy, depends on: 20:03 #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 vorlon: ? 20:04 This is regarding the seeded snaps, right? 20:04 doesn't look like he's here 20:04 sil2100: yeah, I think so 20:05 just giving him some time to respond, since he did chime in in #ubuntu-meeting-2 earlier 20:06 oh! didn't notice 20:06 cyphermox: sorry - yes, still carry over 20:06 and well, many action items are his, too 20:06 ack! 20:06 #subtopic ACTION: vorlon to reply to seeded snap upload permissions question on list 20:06 same? 20:06 basically no movement on any of mine since the last meeting 20:06 ah, ok 20:07 (there was a Canonical midcycle roadmap sprint in the middle) 20:07 #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 ack. 20:07 *lurks TB meeting* 20:07 vorlon: do you know about xnox's? 20:07 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 same for me, apologies, I was supposed to ping him about that 20:08 oh, right, sorry 20:08 the last action items are just that 20:08 #subtopic ACTION: mdeslaur to follow up with xnox about OEM archive documentation 20:08 #subtopic ACTION: mdeslaur to follow up on xnox's track clarification post to the list from 2020-08-12 20:08 carrying those as well then 20:08 carry forward both of mine, yes, thanks 20:08 should we reassign some things? would that help? 20:08 oh if anyone wants one of mine, feel free to steal it ;) 20:09 likewise ;) 20:09 haha 20:09 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:10 I can follow up with Dimitri if needed 20:10 So you can re-assign it to me, my first TB task! yay 20:10 sil2100: thanks, I'd appreciate it 20:10 ok 20:11 #action sil2100 to follow up with xnox about OEM archive documentation 20:11 * meetingology sil2100 to follow up with xnox about OEM archive documentation 20:11 carrying the rest, I'll clean up the wiki 20:11 #topic Other agenda items 20:11 There were none on the Agenda wiki page... 20:12 at least, as of half an hour ago when I prepared for the meeting 20:12 #topic Pending mailing list items 20:12 I don't know that any were definitely missed; but in case: 20:12 #subtopic Proposal for exception to existing fwupd SRU policy 20:12 I don't think that request has been addressed yet. 20:12 I haven't had a chance to digest that one yet fwiw, sorry 20:12 did anyone respond on this one from Mario? 20:12 ok 20:13 I'm inclined to consider that as standard hardware enablement? 20:13 Though I think maybe it's one for the SRU team, not the TB? 20:13 (at first blush, I am unenthusiastic about it) 20:13 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 (from memory) 20:13 aye 20:13 rbasak: ah; I thought it went to the TB because you referred it there from the SRU team? 20:14 No that was Thunderbird 20:14 oh ok 20:14 (that request involved deliberately breaking some packages, so I didn't think it fitted into the scope of the existing delegation) 20:15 to me, fwupd point the first seems like HWE 20:15 does someone want to respond and kick it back to the SRU team then? 20:15 and fwupd point second sounds a lot like a standard SRU bugfix 20:15 I'll respond 20:16 (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 sure 20:16 so you're going as letting the SRU team decide just this one, and then we think more about a stnading exception? 20:16 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:17 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 The SRU team would grant a standing exception still though? 20:18 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 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 +1 20:18 #action cyphermox to respond to Mario's SRU exception request, this is handed back to the SRU team. 20:18 * meetingology cyphermox to respond to Mario's SRU exception request, this is handed back to the SRU team. 20:18 that sounds right? 20:18 +1 20:18 #subtopic Updating thunderbird from 68 to 78 in focal 20:19 rbasak: you want to tell us more about the current state of this, as you've been most involved in the thread? 20:19 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 so the two packages are tinyjsd and jsunit, which AFAIK existed solely to be able to build enigmail 20:21 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 I believe the appropriate resolution has been agreed. We're just waiting on uploads. 20:21 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 I believe they're being turned into dummy packages - that was mdeslaur's proposal, and nobody objected. 20:22 ok 20:22 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 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:24 yes, I'm in agreement 20:24 +1 20:24 +1 20:24 +1 20:24 #agreed vorlon's thoughts on thunderbird process 20:24 AGREED: vorlon's thoughts on thunderbird process 20:25 I like Robie's proposition to make sure to document this somewhere 20:25 yup 20:25 #subtopic Use of the TB mailing list 20:25 was there anything left to discuss on that one? 20:25 *raises hand with CC hat on* 20:25 teward: hi! 20:26 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 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:27 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 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 Oh 20:27 cyphermox: then as soon as that's updated, I won't have a reason to complain :0 20:27 I did have a proposal for basically that that remains outstanding on the list. 20:28 ok 20:28 https://lists.ubuntu.com/archives/technical-board/2021-January/002532.html 20:28 AIUI no members of the tb are still administrators of the mailing list and cannot update the description? 20:28 +1 on rbasak's proposal 20:28 vorlon: CC has admin 20:28 I like Robie's proposition to make sure to document this somewhere> Should we require this then, in approving the Thunderbird request? 20:28 you choose wording, we'll toss it up 20:28 teward: ok 20:28 (I was in it yesterday in 'read only' mode, you can consider me PoC for this one) 20:28 (if you need a dedicated PoC) 20:29 ("read only" meaning I was looking @ settings but not tweaking ;) ) 20:29 rbasak: your proposal for the ML was straight up agreeing to the wording, correct? 20:29 cyphermox: correct 20:29 Just the wording change, which also means that nothing else changes. 20:30 I'm +1 on your wording. 20:30 +1 20:31 +1 20:31 Thanks! 20:31 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 Action to teward then please? 20:31 #agreed Make use of rbasak's copy suggestion for updating the mailing list's "About" section. 20:31 AGREED: Make use of rbasak's copy suggestion for updating the mailing list's "About" section. 20:31 #action teward / community council to update TB mailing list "About" section with agreed upon wording 20:31 * meetingology teward / community council to update TB mailing list "About" section with agreed upon wording 20:31 Thank you! 20:31 ahah, I was just typing that 20:32 cyphermox: i was already ahead of you ;) 20:32 sorry :) 20:32 (i know i'm not chair and asserted it with op but xD) 20:32 Interesting to know that works 20:32 teward: I don't feel like it's likely we'd need admin all that much 20:32 since we do have moderation 20:32 cyphermox: ack, works for me, less people with the admin password the better 20:32 I'm happy with it as is. We can change things if something comes up. 20:32 (in terms of security) 20:32 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:33 vorlon: that's what I'd expect 20:33 I would just not like the CC making config changes without consulting the TB :) 20:33 Before we continue, I have one question above on the Thunderbird exception please 20:33 #agreed TB does not need admin access to the ML at this point in time 20:33 AGREED: TB does not need admin access to the ML at this point in time 20:33 rbasak: yes, I just wanted to conclude one topic at a time 20:33 Sure 20:33 #subtopic Back on thunderbird 20:33 vorlon: that's a given as well, we wouldn't touch anything unless either ERR:CRITICAL or ERR:TBConsulted 20:34 So from above, for clarity 20:34 rbasak: you were asking about whether we'd require the write-up? 20:34 I like Robie's proposition to make sure to document this somewhere> Should we require this then, in approving the Thunderbird request? 20:34 Right 20:34 I would like a bit of a cultural shift in Ubuntu in this regard. 20:34 Of everyone doing a better job of writing up user-impacting changes. 20:35 what form would that take though? 20:35 things are often documented by way of mailing list, for better or for worse :) 20:35 I don't really mind what form, as long as it's a noise-free single summarised and linkable explanation. 20:35 I wouldn't want to mandate anything specific either, really. 20:36 I think this is just that think that probably belongs to devel or devel-announce? 20:36 Yeah, one or both even 20:36 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 indeed 20:37 also, release notes 20:37 Well, release notes are fine when we're doing point-releases or releases 20:37 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 But for changes in stable series before a release is happening - we don't have a good place for that right now 20:37 as a community member (not my CC hat!) I would agree with better Release Notes and such 20:37 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:38 So for instance for .2 it makes sense to document it in the release notes 20:38 sil2100: that arguably should show up in Changes doc for a stable release; but in the meantime a mailing list suffices 20:38 But inbetween .2 and .3, it's a bit confisuing if we put it there before release 20:38 I see we're in full agreement 20:38 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 well, the Changes/ Release notes could still just point to the mailing list post 20:38 So would a -devel or -devel-announce ML post 20:39 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 "XYZ changed, causes FGH to be broken, see for full rationale" 20:39 nah 20:40 does -devel / -devel-announce post sound fine for everyone to document this, and who will respond on the thread? 20:41 (I'm +1) 20:41 A question for everyone first. Do you want to mandate a specific method? Because I don't. 20:41 nah, I'd just recommend it as part of "please write documentation for this change" 20:41 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 Recommend instead of mandate is good. 20:42 Since it's then easier to get all the interesting stuff from single place to put on the release notes 20:42 So is everyone suggesting recommendations here, and not a mandate? 20:42 MUST document, MAY use established mailing lists -devel or -devel-announce 20:42 +1 20:43 +1 20:43 apologies for using RFC parlance 20:43 The clarity is good :) 20:44 mdeslaur, vorlon ? 20:44 0 20:44 ok 20:44 what is the full scope of this proposed MUST... and where is the documentation requirement to be documented? 20:45 that's a good point, this should go with an update of what we're expecting, say, on the wiki 20:45 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 (as at attempt at defining it) 20:45 so this is for SRU changes 20:45 ? 20:46 any reason not to have this dealt with internal to the SRU team? 20:46 Those are general requirements that I think we can choose to apply to any decision we're asked to make. 20:46 And, if we want, recommend that other teams do the same. 20:46 SRU justification is normally documented on bug reports though 20:46 ok, for TB decisions? 20:46 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 the existing wiki structure is currently suboptimal 20:46 Yes, for TB decisions would be a start. 20:47 as "Known Potential Regressions" ;) 20:47 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 it can be very difficult to locate historical TB decisions because basically all we have is an index of TB meeting logs 20:47 vorlon: i have a question for you on that 20:47 are we going to commit to keeping a directory of decisions in the wiki? 20:47 that's why we were supposed to have the TeamReports, I think 20:47 have you considered asking IS to create a Discourse section for you to drop all the decisions as independent threads there? 20:48 (mailing lists definitely don't help with the "locate past decisions" problem) 20:48 well, perhaps that doesn't quite make it easier to find 20:48 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 (permissions, etc. as Discourse isn't... kind... with perms) 20:48 (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 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 ) 20:48 directory> yes, that works. Very easy if we're going to have linkable decisions. 20:48 vorlon: ack, just thought I'd ask since we're all on it (though I'm not TB) 20:49 this is quite a few different work items 20:49 so do we agree to start documenting by example? 20:50 I'm not sure "documenting by example" is exactly what we just discussed. Let me see if I can summarise... 20:50 it's only part of it 20:50 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:51 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 nd any available workarounds for users affected by downsides" 20:51 2) Recommend, but not require, somewhere specific for this 20:51 3) Operate a directory somewhere of these summaries 20:52 sounds to me more and more like bugs are the right place to have all this 20:52 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:53 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 In my enumerated list above, I only really care about 1, FWIW. The other two were suggested additions, AIUI. 20:55 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 To be clear, by "decision-by-decision basis" I mean "for decision A, please document; for decision B, no need" 20:55 like, actions for the right now, this particular request (Thunderbird updates) 20:55 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:56 This is why I liked the idea of simply following up with an e-mail to devel or devel-announce 20:56 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:57 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 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 cyphermox: sure 20:57 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:58 and in parallel we can address just the thunderbird case right now, (and how do we do so?) 20:58 mdeslaur: +1 20:58 Personally, I don't even care to require the linking. That can be done any time afterwards if it comes up. 20:59 rbasak: changelog should include all you need to understand the decision, for developers 20:59 (I'd prefer to keep the requirements down and the proposal to be simple) 20:59 rbasak: but users are not developers and are unliekly to look at changelog 20:59 I think we're bikeshedding this too much. 21:00 I don't know that we are -- there's competing requirements 21:00 Can we just agree that we'd like a documentation summary, and leave the rest? 21:00 it needs to be written somewhere, but if there is already a SRU in progress won't we already have everything there? 21:00 This doesn't need to be perfect; just a start. 21:01 competing requirements> IMHO, you're all adding requirements when there's no need. 21:01 you want the decision to be written down somewhere, that's understood 21:01 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:02 AFAIK the only thing that goes with that is that this summary needs to be findable somewhere in 6 months 21:02 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 leave it to the developers for now and we can copy-paste as needed? 21:03 +12 21:03 that works 21:03 agreement? 21:03 Apologies everyone but I have to go AFK now o/ 21:03 But seems fine for me 21:04 #action rbasak to write up proposal for how to do decision documentation for the future 21:04 * meetingology rbasak to write up proposal for how to do decision documentation for the future 21:04 +1 on requesting a summary 21:04 alrighty 21:04 #agreed thunderbird changes should include a summary of the decisions / changes written somewhere; left at the discretion of the developers 21:04 AGREED: thunderbird changes should include a summary of the decisions / changes written somewhere; left at the discretion of the developers 21:05 (I mean this paritcular request, to be clear) 21:05 #topic Community bugs 21:05 "There are currently no open bugs." 21:05 I'm moving along fastish, because I'm also busy with other things, but please chime in if I'm going too fast 21:06 #topic Chair for next meeting 21:06 *is waiting for AOB for a semi-big issue* 21:06 I think this ends up being rbasak's turn, with vorlon as backup. 21:06 ah? 21:06 fast> fine by me, we're over time :) 21:06 teward: if it's big enough, would it be better written in the ML? 21:07 or do you think it needs to be addressed now, since we're indeed over time? :) 21:07 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 I agree with teward that it is rather urgent. 21:07 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:08 kernel panics in VBox drivers, hardware drivers for networking going AWOL/fubar, etc. 21:08 according to sarnold there's Foundations / Desktop / Kernel at fault 21:08 according to rbasak it's Desktop partly at fault for the original decision 21:08 more like, I'm not sure who exactly made that decision :) 21:08 and according to me it's *everyone* at fault 21:09 so I'd like the TB to spearhead a top-down approach of poking around at this - determine: 21:09 Well hold on, I didn't say fault 21:09 I'm not fond of assigning fault, tbh, though a post-mortem of a failure is beneficial 21:09 rbasak: well i'm half-summarizing it :P 21:09 i'd like TB to post-mortem this 21:09 and poke and see what broke, where, and how this can be averted in the future 21:09 I would expect the desktop team to lead for what is primarily a desktop regression, that's all. 21:09 fwiw there was an internal meeting this morning to discuss the lack of communication of this new behavior, which will be addressed 21:09 TIL we're automatically installing HWE stuff 21:09 ^ this 21:10 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 I see there being two parts to this. 21:10 so are we expecting a statement from the TB about this? 21:10 1) the new behaviour 21:10 2) the regressions 21:10 or a summary of what happened and how it can be avoided in the future 21:10 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 from sarnold i was told there was an autopkgtest problem where dkms stuff wasn't autopkgtested with HWE enabled was put into place 21:11 but that's second-hand knowledge 21:11 (this does NOT have me with my CC hat by the way, but as a concerned member of the community) 21:11 severely concerned* 21:11 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 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 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 the fact that the hwe was released before the .2 release *also* surprised a lot of people 21:12 ^ 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 or at least we'll need somebody to lead putting things together 21:12 and chasing people for answers 21:12 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:13 teward: it's big enough perhaps a ML post would help 21:13 I'm getting lost in it all 21:13 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 cyphermox: welcome to me when I was first responding to this saying "WHUT>>>?" 21:13 vorlon: ah, thanks 21:13 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 teward: yep. 21:14 vorlon: but them being installed on to existing users before that .2 is out is surprising and new this time around 21:14 yes 21:17 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:18 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 From an Ubuntu governance perspective, I don't think that's acceptable. 21:18 and from my CC perspective, I don't find it acceptable nobody's come forward with *any* information about the core cause, etc. 21:19 rbasak: do you want to take point? 21:19 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 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 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:20 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 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 so the release team already has that on their radar? 21:21 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 cyphermox: yes, we have action items regarding communication, changing the documentation and release notes, everything assigned to be done before .2 is out 21:22 And the kernel team, as mentioned by vorlon, is actively working on the introduced regressions 21:22 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:23 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 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:24 vorlon: I think I covered that above? 21:25 To whom> to the community. Like before, I don't care where, as long as it can be linked to. 21:25 rbasak: teward: are the bug, a future post to ubuntu-devel and discourse addressing your concerns? 21:25 this does communicate things to the community, in various methods 21:25 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:26 there's alreday the bug description that looks okay enough to me to describe what happened 21:26 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 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 because that's... a LOT more problematic now 21:26 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 Thanks sil2100 21:26 okay 21:26 so here it is 21:27 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 #action cyphermox to pester the release team before next meeting about documentation for the HWE changes in focal. 21:27 * meetingology cyphermox to pester the release team before next meeting about documentation for the HWE changes in focal. 21:27 the next meeting is in two weeks, we'd want something before then, I agree 21:27 as to when, if people already know to make such announcements/documentation, I'm inclined to let them work. 21:28 (as above, as long as it doesn't end up taking multi-months) 21:28 am I missing something? 21:28 nope 21:29 cool 21:29 #endmeeting 21:29 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 in a way that won't kill everything 21:29 that's all :) 21:29 sil2100: if you dont' mind pinging me when that notie is made that'd eb great. 21:29 s/notie/notice/ 21:29 o/ 21:29 changes sometimes happen; it's not out of malice 21:29 Suar 21:30