19:06 <mwhudson> #startmeeting Ubuntu technical board
19:06 <meetingology> Meeting started at 19:06:54 UTC.  The chair is mwhudson.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
19:06 <meetingology> Available commands: action, commands, idea, info, link, nick
19:07 <mwhudson> #topic Official status of riscv64 (mwhudson)
19:07 <mwhudson> we talked about this last time (6 weeks ago now?) and the conversation kind of petered out iirc
19:08 <seb128> https://irclogs.ubuntu.com/2025/05/20/%23ubuntu-meeting.html for the record
19:08 <rbasak> My opinion is: delegate the decision to the release team. Suggest that they should consider if they consider a suitable quality bar to be met, in light of concerns already raised on the list, but leave it to them to decide if they want it to be official.
19:09 <seb128> I'm reading the log again to try to refresh that conversation
19:09 <mwhudson> my recollection is that the conclusions were: 1) the official flag is entirely cosmetic from a technical point of view 2) the main thing about riscv64 that makes people leery about riscv64 is that security updates can be delayed because the builders are slow
19:09 <seb128> ah, yes, I was also +1 on delegating that decision to the r-t
19:10 <mwhudson> ok i am fine with that as a conclusion
19:10 <mwhudson> so someone needs to take it to the r-t then?
19:10 <seb128> also 2) didn't feel like something we could easily get resolved and security team seemed to be ok with it as long as it's documented
19:11 <seb128> I guess?
19:11 <seb128> I can take an action item to talk to the r-t about it
19:12 <mwhudson> #action seb128 to contact release team about this
19:12 * meetingology seb128 to contact release team about this
19:12 <mwhudson> thanks
19:12 <mwhudson> #topic seb128 to read up on Open Source AI Definition and consideration of proposal to endorse the definition
19:12 <seb128> I did that now
19:14 <mwhudson> so rbasak's proposal was "1) take the view (as the TB) that any endorseement we may choose to make on this topic should apply to the archive 2) defer consideration on endorsing OSAID until the Debian process is complete"
19:14 <mwhudson> i'm not sure what's going on with Debian's process rn, i think the proposed GR got withdrawn?
19:14 <rbasak> Indeed
19:14 <rbasak> Yeah that happened since IIUC. I haven't been keeping up.
19:14 <seb128> Right, doesn't look like Debian will take a position on that yet
19:15 <rbasak> So we could still agree on (1) above
19:15 <rbasak> For (2), perhaps we're forced to make a decision rather than wait for Debian
19:15 <seb128> Indeed
19:16 <seb128> I've a feeling it could take a while for Debian so it would probably be better to not block on them
19:16 <rbasak> (where a decision on (2) could mean no endorsement of anything, endording OSAID, or taking a different position entirely)
19:17 <mwhudson> my having-thought-about-it-a-bit-but-not-an-expert view is that i would not be happy to accept into the archive a model where training data is not available
19:17 <rbasak> For (2), I currently lean towards the only option on Debian's now-withdrawn GR
19:17 <rbasak> Same as mwhudson then I think
19:17 <mwhudson> or rather, to do that would require an explicit decision and not be covered under existing policies
19:17 <mwhudson> (and i'd have pretty mixed feelings about changing policies to allow this)
19:17 <rbasak> OTOH, I don't have a problem with making it easier for Ubuntu users to consume models that don't come from the official Ubuntu archive, especially if they comply with OSAID
19:18 <mwhudson> so um.
19:18 <mwhudson> i guess we are not going to endorse the OSAID at this time?
19:19 <rbasak> This might be behind a warning similar to the proprietary driver warning Ubuntu had a long time ago for example, IIRC, along the lines of "you can do this but understand that without sources it's not great"
19:19 <rbasak> Yeah if mwhudson and I agree then it seems unlikely we're in a position to endorse OSAID then.
19:20 <mwhudson> seb128: do you agree? have any more comments?
19:21 <rbasak> Oh, one more thought. restricted/multiverse?
19:21 <mwhudson> rbasak: oh argl
19:21 <seb128> I was going to mention that since you were comparing to proprietary drivers
19:21 <rbasak> multiverse autosyncs from Debian non-free, right? So if something is OSAID compliant but without training data available, would it be acceptable to Debian non-free?
19:22 <mwhudson> given some of the things in non-free already i'd assume so
19:22 <mwhudson> and i can't really think of a reason to keep an OSAID model out of multiverse
19:22 <mwhudson> (mind you models that do not meet the OSAID would probably be ok for multiverse too?)
19:22 <rbasak> IIUC, non-free would be allowed
19:23 <rbasak> So if availability of training data is the only issue, and it's otherwise compliant (including OSAID), then I think multiverse would be fine under our current rules.
19:24 <seb128> agreed
19:24 <mwhudson> agreed
19:24 <rbasak> I would like to emphasize that I do not want Ubuntu users to be "left behind" here - just that I think it should be done through multiverse or similar mechanisms if required. Hopefully that doesn't actually block anything, although I appreciate split-packaging might be required and a bit painful.
19:25 <rbasak> If there's a real world issue then I encourage that to be brought up on the TB list for us to consider the specifics.
19:25 <rbasak> So where are we with a TB decision?
19:25 <mwhudson> i think tbh people are not looking to their distro's to get access to these models (yet?)
19:26 <mwhudson> *distro's repositories
19:26 <rbasak> IIUC, there's some free software out there now that is enhanced with these models, and so there's a question of how to package them.
19:27 <rbasak> (in distro)
19:27 <rbasak> Of course we're reliant on volunteers to do that packaging whether in Debian or in Ubuntu
19:27 <mwhudson> rbasak: i guess the decision is to take no explicit action (we are not endorsing the OSAID, I don't think we need to explicit tell people that multiverse is ok) and just stop talking about it until it comes up again?
19:27 <rbasak> mwhudson: essentially yes. I think we need to respond to Merlijn's thread stating that though
19:28 <seb128> I would be +1 on that
19:28 <seb128> does anyone want to take an action item to draft / write that reply?
19:28 <rbasak> If everyone's in broad agreement with my opinions above, I'm OK to draft something. I'd want you to approve explicitly before posting.
19:29 <mwhudson> i guess maybe this will come back to us when there is a concrete piece of software to discuss and that's fine
19:29 <mwhudson> rbasak: +1
19:29 <rbasak> Is there anything I've said in my opinion above that you wouldn't want me to include?
19:29 <rbasak> (or to modify?)
19:29 <mwhudson> rbasak: i guess it would be great if you have time to try to understand what happened in the debian discussion (i don't think i have time for this though)
19:30 <rbasak> I did vaguely follow along. I'll happily spend 20 minutes on that but I'm restricted on time too at the moment.
19:31 <seb128> I do agree with what you wrote earlier and I've no extra comment/suggesting
19:31 <seb128> suggestion
19:31 <mwhudson> ok
19:31 <seb128> and yes, let's read your draft and validate before posting
19:31 <seb128> thanks
19:32 <mwhudson> #action rbasak to draft a response to merlijn's email thread for review
19:32 * meetingology rbasak to draft a response to merlijn's email thread for review
19:32 <mwhudson> heh next one is "TB to vote on the proposal at the next meeting" oh well
19:32 <mwhudson> #topic mwhudson to remove the TB from ~launchpad-buildd-admins
19:32 <mwhudson> i did this, or rather caused it to happen
19:32 <mwhudson> #topic rbasak to reply to the release team and clarify the LTS flavor delegation process
19:32 <rbasak> I moderated the email confirming that earlier :)
19:33 <rbasak> Hmm. Did I do that?
19:33 <mwhudson> i don't see any email about that i think
19:33 <rbasak> I did not
19:33 <rbasak> I've found the email I need to reply to
19:33 <rbasak> Carry this one over please
19:33 <mwhudson> ack
19:34 <mwhudson> #topic seb128 to continue working with AA and Release teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations
19:34 <seb128> carry over please (we are working on publishing new AA documentation, which I hope will be part of resolving that one)
19:34 <mwhudson> yeah hopefully this can get covered as part of the ubuntu project docs effort
19:34 <mwhudson> #topic teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC
19:35 <mwhudson> teward appears to be afk so carry this over i guess
19:35 <mwhudson> #topic teward to write up a proposal for how the move away from the wiki will work
19:35 <mwhudson> ditto
19:35 <mwhudson> (does this cover moving to matrix for meetings?)
19:35 <mwhudson> #topic [rbasak] DMB appointment process
19:36 <rbasak> I believe he's working on that regardless, though not with a TB/CC hat
19:36 <rbasak> Thread link: https://lists.ubuntu.com/archives/ubuntu-devel/2025-June/043369.html
19:36 <mwhudson> #link https://lists.ubuntu.com/archives/ubuntu-devel/2025-June/043369.html
19:36 <rbasak> There have been a couple of suggestions of tweaks to my proposal that I accept
19:37 <rbasak> If we accept the change, then I intend to document it, and I'd already started doing that as something that the TB could more easily consider (than a thread)
19:37 <seb128> I think the proposal makes sense yes
19:37 <mwhudson> i support the intent for sure
19:37 <rbasak> One moment
19:38 <mwhudson> rbasak: will the change be a PR to the docs or something else?
19:39 <rbasak> I'll file a PR, sure
19:39 <rbasak> But here's the draft:
19:39 <rbasak> https://paste.ubuntu.com/p/ZrTXdHhM3P/
19:40 <rbasak> Maybe we could agree to the draft in principle as a formal TB decision just to get things moving with the new DMB appointments?
19:40 <rbasak> Formally, if we could delegate the copyediting to me and trust me to get the intent right, I'd appreciate it - rather than getting blocked on PR approvals before landing.
19:42 <seb128> I'm reading
19:42 <rbasak> I think I need to make it clear that a member should leave the team if they wish to resign. There are probably some other minor details to correct. I'll do that later before filing the PR.
19:43 <mwhudson> rbasak: so there is a related old issue about how to remove DMB members who are no longer active, so the DMB can reach quorom but i guess that is a separate topic
19:43 <rbasak> That's a good point.
19:44 <mwhudson> so i'm +1 on this wording and fine with minor copyedits before formal promulgation or whatever word we want to use
19:44 <rbasak> I think I should fix that now, but let's get agreement on this as it is to get the new appointments going please, and then I'll write an amendment on how I think that should work.
19:44 <seb128> I was checking about the 2 years vs 1 year, I see that was feedback from Utkarsh and I guess that makes sense, it's hard enough to find people to volunteer, that might help a bit to not scare people away
19:44 <rbasak> (and I'll bring that amendment back to the TB before we commit)
19:45 <seb128> +1 from me
19:45 <rbasak> seb128: yes - I accepted that and changed the text to one year.
19:45 <mwhudson> (i mean basically, if someone is inactive the DMB should complain to TB and we either agree and remove them or object)
19:45 <rbasak> Thanks!
19:45 <rbasak> mwhudson: basically exactly that :)
19:45 <mwhudson> ok so
19:46 <mwhudson> #agreed https://paste.ubuntu.com/p/ZrTXdHhM3P/ or a lightly copyedited version is agreed TB policy on DMB staffing
19:46 <meetingology> AGREED: https://paste.ubuntu.com/p/ZrTXdHhM3P/ or a lightly copyedited version is agreed TB policy on DMB staffing
19:46 <mwhudson> #topic Scan the mailing list archive for anything we missed (standing item)
19:46 <rbasak> Thanks!
19:47 <mwhudson> well there is the installer topic
19:47 <mwhudson> (i have still not read all the threads about this closely :( )
19:48 <mwhudson> rbasak, seb128: do you have thoughts about this?
19:49 <rbasak> I don't think it's a TB matter, unless Jon wishes to ask the TB to force the flavours to switch (I don't think he does?)
19:49 <seb128> that was discussed between Jon and the flavors lead at a flavor sync meeting since
19:49 <seb128> leads
19:50 <rbasak> I haven't seen any reason that the TB should force anything on this matter, unless I'm missing something.
19:50 <seb128> my understanding is that they found an agreement and that there is no need for the TB to be involved
19:50 <rbasak> Perfect
19:50 <mwhudson> that sounds fine with me (i am happy not to have an opinion on this)
19:50 <mwhudson> ok great
19:50 <mwhudson> #topic AOB
19:50 <seb128> not from me
19:50 <rbasak> Nothing from me
19:50 <mwhudson> oh i am doing this out of order sorry
19:51 <mwhudson> nothing from me
19:51 <mwhudson> #topic Check up on community bugs and techboard bugs (standing item)
19:51 <mwhudson> no activity on any of these i think
19:51 <mwhudson> (we have talked about 3/4 open techboard bugs already!)
19:51 <mwhudson> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)
19:52 <mwhudson> as i said on matrix i am away for the next two meetings so dibs not me
19:52 <seb128> well you just chaired anyway
19:53 <seb128> I think it's teward's turn again since he missed his shift today and rbasak as backup
19:53 <mwhudson> makes sense to me
19:53 <mwhudson> (did anyone ping him on matrix? oh well)
19:54 <rbasak> ack
19:54 <mwhudson> #agreed teward to chair next meeting, rbasak as backup
19:54 <meetingology> AGREED: teward to chair next meeting, rbasak as backup
19:54 <mwhudson> ok i think we're done?
19:54 <mwhudson> i'll try to update the agenda this time :-)
19:57 <mwhudson> #endmeeting