19:07 #startmeeting 19:07 Meeting started Tue May 22 19:07:27 2018 UTC. The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 19:07 19:07 Available commands: action commands idea info link nick 19:07 sorry :) 19:08 (I'll go ahead and chair; I think I ran the last one I attended, but also there were no logs because of someone vandalizing the bot, and no one updated the wiki page, so...) 19:08 [TOPIC] Apologies 19:08 none recorded 19:08 stgraber beat that topic. 19:08 [TOPIC] Action review 19:08 infinity: heh 19:08 * slangasek flexiondotorg To follow-up on-list with design review to address MATE Boutique security/consent concerns. 19:09 oops, that needs amended 19:09 That action seems old. 19:09 * slangasek Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns. 19:09 there I fixed it 19:09 sorry 19:09 infinity: it's old but there still hasn't been any on-list follow-up 19:10 Wimpress said there is work in progress, but given that this was driven by TB concerns about security UX, I don't think it should fall off our nag list 19:10 Check. 19:10 * slangasek infinity to call for confirmation of LTS status from all flavours. 19:10 Done. 19:10 I'm hoping we can consider that done 19:10 * slangasek infinity to ask maas team to prepare SRU exception policy à la CurtinUpdates 19:10 Carry. 19:11 infinity: ok. while sprinting earlier this month, there was a MAAS SRU referencing https://wiki.ubuntu.com/MAASUpdates; so it would be good to have that formalized 19:11 * slangasek slangasek and mdeslaur to more clearly define third party seeded snap security policy 19:11 mdeslaur: did you do this when I wasn't looking? ;) 19:11 uh, no ;( 19:11 ok ;) 19:11 so, carry 19:12 * slangasek tsimonq2 to email proposed policy for flavor-notification of daemons being added to all flavors (e.g. snapd into desktop-common) 19:12 Darn it. 19:12 tsimonq2: ^^ I don't recall seeing an email about this, so here's a formal TB nag 19:12 To be fair, flavor relationships have changed. 19:12 I'll bring it up. 19:12 Thanks. 19:13 tsimonq2: changed how? 19:13 Was it not discussed when it was added to desktop-common, and maybe lubuntu just opted out of the discussion because they were (incorrectly, IMO) not using -common at the time? 19:13 I absolutely stand by the assertion that desktop-common should be common to *all* *buntu desktops, so if we're adding things there, concensus should be found. 19:14 slangasek: 19:14 (just as minimal and standard are common to all flavours) 19:14 We communicate a lot more. #ubuntu-flavors among other things is now there, so we talk regularly now. I'll bring it up. 19:14 infinity: snapd was not discussed with the flavors before addition to desktop-common, no; we had a conversation at a previous meeting about why that was, and the outcome was for tsimonq2 to propose a policy on how to handle this 19:14 slangasek: Ahh, kay. So this is an old action, not a result of my foisting desktop-common on lubuntu with the recent seed shuffle. Kay. 19:14 infinity: And with >= Cosmic, I do agree. 19:15 tsimonq2: #ubuntu-flavors is not the right venue for such a thing (and though my objection counts for little, I object to creating a new IRC channel for this); the proposal should happen on the existing central mailing lists 19:15 I would (somewha 19:15 grr /me returned early 19:15 I would also (somewha 19:15 lol 19:15 For the right price. 19:15 I mean, discuss to your heart's content, but the proposed policy should go to techboard and ubuntu-release/ubuntu-devel 19:16 I definitely don't mind -release being used by flavour leads for inter-flavour policy, and obviously devel/devel-discuss when you want wider input than just fellow leads. 19:16 I would agree that the IRC channel isn't the right place, but in general, conversation about how exactly to go about this needs to happen in a more formal place. I was just noting the IRC channel as an example of ways flavors are collaborating more nowadays. 19:16 yes 19:16 -release is very low traffic, and I consider that on-topic with those hats on. 19:17 moving on 19:17 slangasek: I'm agreed on where to send the policy. 19:17 OK, thanks TB. 19:17 tsimonq2: ok, grand :) 19:17 [TOPIC] Review of the seeded snaps policy 19:17 this is a carry-over on the agenda and probably doesn't need any discussion today, given mdeslaur's and my action item 19:18 however I'm going to leave it on the agenda page for next time so that I have appropriate levels of guilt about getting that done 19:18 [TOPIC] LP: #1770748: Dropping patches added for main inclusion and delegation of maintainership 19:18 doko_: are you around? 19:18 this was added to the agenda by doko_, who informed me earlier today that he would not be able to attend the meeting 19:18 I don't know that we need to tackle this without all the parties to the discussion present 19:19 unless some member of the TB is particularly keen to dive into the topic right now? 19:19 I felt it was premature for a TB decision on the issues 19:19 I don't think there is much for the TB there either 19:19 I think it could have been settled by two adults in #ubuntu-devel without escalating, but maybe not. :P 19:20 jbicha: fwiw I don't necessarily think the TB needs to decide on this; I redirected doko from myself to the TB because doko appeared to have invoked me to throw my weight around on the issue, and I declined to do so in a personal capacity 19:20 I phrase the issues a bit differently than do_ko 19:21 jbicha: if you and doko come to some sort of agreement that you're both happy with, that's fine. I think there are also policy questions that are larger than the particular disagreement between you and doko, and we may still want the TB to provide guidance 19:21 I see 2 issues: whether C++ libraries in main must have symbols files; and whether Foundations should "own" (or "maintain" or whatever) ilmbase 19:21 jbicha: FWIW, while I don't agree with his handling (and escalation) of the issue, I do agree that it you were tired of waiting around for him to merge, you probably should have merged with symbols files, not synced. 19:22 the symbols file question is being discussed on the ubuntu-devel list 19:22 jbicha, I don't think the packages "ownership" is a TB matter 19:22 The secondary question of the usefulness of symbols files in C++ projects (especially ones with questionable symbol visibility policies) is definitely not something I think the TB needs to weigh in on. 19:22 I hear that Desktop & Foundations teams are going to have a meeting soon to discuss various issues so the ownership issue can be discussed there 19:22 jbicha: the question of what team owns a package for purposes main is indeed not a TB question, since main is a matter of Canonical sponsorship 19:23 "for purposes main" oh look I'm accidentally 18th century English 19:23 heh 19:24 That construct is back in vogue in 21st century en_GB. 19:24 You're hip. 19:24 In the wrong country. 19:24 interestingly, acheronuk added a debdiff to the bug to add the symbols. Someone could upload that to resolve some of the issue or lower the urgency 19:25 jbicha: More importantly than re-adding the symbols files is actually auditing the changes between old and new, since that's the point of symbols files in the first place. 19:25 If we're just going to effectively delete and regenerate them on each upload, they're entirely useless. 19:25 I'm not interested in sponsoring it at this point because I'm interested in resolving the question of whether the symbols file is mandatory (for future uploads) 19:26 being mandatory and removing them is two different things 19:26 so I'm shying away from that question for the moment because I don't think we should have a partial discussion without all parties present 19:26 jbicha: I'm not deeply interested in diving into the list discussion, but I think making symbols files truly useful in Debian/Ubuntu C++ packages might first need some Debian library policy surrounding best practices for symbol visibility. 19:26 mdeslaur: it was Debian that removed the symbols file and do_ko added it back without discussion 19:26 I mean, I can opine, but in the context of the current TB meeting I think we should postpone 19:27 jbicha: C++ symbols files can be quite clean if your project doesn't export a ton of pointless cruft it shouldn't. 19:27 https://launchpadlibrarian.net/371130484/restoresymbols.debdiff 19:27 point of order ;) 19:28 if we want to argue this as individual core devs instead of as the TB, could we defer it until after we close out this meeting? or if you're disagreeing with me about postponing, then I'll dive full in 19:28 +1 from me for postponing 19:28 Right, I'll shut up. ;) 19:28 ok :) 19:29 [TOPIC] Scan the mailing list archive for anything we missed (standing item) 19:29 [LINK] https://lists.ubuntu.com/archives/technical-board/2018-May/thread.html 19:29 DMB members stuff, strictly administrative, has been handled 19:30 wxl's request for input on quorum - I followed up, I think my comments uncontroversial but https://community.ubuntu.com/t/open-discussion-meetings-quorum/5966/5 if anyone else wants to weigh in 19:30 nothing else on list 19:30 [TOPIC] Check up on community bugs (standing item) 19:30 [LINK] https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard 19:30 zarro boogs 19:30 [TOPIC] Select a chair for the next meeting 19:31 is that stgraber, with infinity backup? 19:31 +1 19:31 fine :) 19:31 technically, we all expire the Sunday before that 19:31 Well, +0.5 19:31 Because I haven't made a short joke in MONTHS. 19:31 who wants to prod about extension + election? 19:31 slangasek: I'll get us extended again, if you promise to chase down sabdfl about an election. 19:31 lol 19:32 [ACTION] infinity to get TB terms re-extended 19:32 * meetingology infinity to get TB terms re-extended 19:32 [ACTION] slangasek to chase sabdfl / CC about election 19:32 * meetingology slangasek to chase sabdfl / CC about election 19:33 [AGREED] next TB meeting, 2018-06-05, 20:00 BST. chair stgraber, backup infinity 19:33 [TOPIC] AOB 19:33 anything else? 19:34 #endmeeting