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
20:00 <mdeslaur> o/
20:00 <cyphermox> #chair cyphermox rbasak
20:00 <meetingology> Current chairs: cyphermox, rbasak
20:00 <cyphermox> #topic Apologies
20:00 <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:01 <sil2100> o/
20:01 <cyphermox> yup
20:01 <cyphermox> ok, moving along
20:01 <cyphermox> #topic Action review
20:01 <cyphermox> #subtopic ACTION: Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns.
20:02 <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:03 <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:04 <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:05 <cyphermox> just giving him some time to respond, since he did chime in in #ubuntu-meeting-2 earlier
20:06 <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:07 <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:08 <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:09 <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:10 <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:11 <cyphermox> #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 <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:12 <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 <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:13 <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:14 <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:15 <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:16 <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:17 <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:18 <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 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:19 <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:21 <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:22 <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:24 <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:25 <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:26 <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:27 <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:28 <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:29 <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:30 <cyphermox> I'm +1 on your wording.
20:30 <sil2100> +1
20:31 <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 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:32 <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:33 <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:34 <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:35 <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:36 <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:37 <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:38 <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:39 <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:40 <cyphermox> does -devel / -devel-announce post  sound fine for everyone to document this, and who will respond on the thread?
20:41 <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:42 <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:43 <rbasak> +1
20:43 <cyphermox> apologies for using RFC parlance
20:43 <rbasak> The clarity is good :)
20:44 <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:45 <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:46 <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:47 <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:48 <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:49 <cyphermox> this is quite a few different work items
20:49 <cyphermox> so do we agree to start documenting by example?
20:50 <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:51 <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:52 <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:53 <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:55 <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:56 <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:57 <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:58 <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:59 <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.
21:00 <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:01 <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:02 <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:03 <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:04 <cyphermox> #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 <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:05 <cyphermox> (I mean this paritcular request, to be clear)
21:05 <cyphermox> #topic Community bugs
21:05 <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:06 <cyphermox> #topic Chair for next meeting
21:06 <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:07 <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:08 <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:09 <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:10 <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:11 <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:12 <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:13 <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:14 <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:17 <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:18 <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:19 <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:20 <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:21 <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:22 <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:23 <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:24 <rbasak> vorlon: I think I covered that above?
21:25 <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:26 <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:27 <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 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:28 <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:29 <cyphermox> cool
21:29 <cyphermox> #endmeeting