17:59:06 #startmeeting 17:59:06 Meeting started Wed Mar 17 17:59:06 2021 UTC. The chair is spwhitton. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:06 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:59:07 spwhitton, sure 17:59:21 #topic Roll Call 17:59:25 Margarita Manterola 17:59:28 Elana Hashman 17:59:29 Sean Whitton 17:59:41 Christoph Berg 18:00:06 Simon McVittie 18:00:11 Niko Tyni 18:00:32 we are not expecting bremner due to hour change, right? 18:00:44 Right, he mentioned he was double booked 18:01:00 I'm sorta here. But I'm mainly in another meeting 18:01:08 oh no, I thought this was a better time for him 18:01:22 no, but we've a topic later on to discuss chanigng th week 18:01:29 ++ 18:01:53 highlight me if you need my wisdom / foolishness 18:01:54 where's gwolf 18:02:11 In Mexico, I assume :) 18:02:21 * ehashman rolls eyes 18:02:24 good one :P 18:02:49 #topic Review of previous meeting AIs 18:02:54 they're all done! 18:02:57 indeed 18:03:06 good time to join for me 18:03:07 anything got anything to mention about theirs? 18:03:17 I'll save mine for the bug discussion 18:03:20 thanks to marga, ehashman and gwolf. 18:03:21 Yes, I've closed the NM bug, Yay! :) 18:03:30 Also, welcome Myon! 18:03:37 thanks 18:03:41 * gwolf Gunnar Wolf 18:03:44 sorry 18:03:44 indeed, welcome Myon 18:03:49 welcome gwolf ;) 18:03:52 +1 18:03:55 And congrats spwhitton on the new appointment :) 18:03:57 I'm following a conference... but I'm here during the meeting 18:03:59 \o/ 18:04:02 Congratulations spwhitton! :-D 18:04:05 thanks marga, and thank you for your work as chair 18:04:07 spwhitton: congrats! 18:04:22 a big thanks to marga and spwhitton 18:04:44 I sent the chair results to the bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985270, but only to the -done address, so I guess it didn't CC the mailing list, sorry about that. 18:04:55 And, of course, thanks a lot to marga 18:04:57 quick link https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985270#61 18:05:31 okay then, let's move on to our one open bug 18:05:33 #topic #976462 - Should dbgsym files be compressed via objcopy --compress-debug-section or not? 18:06:22 ehashman's maths was very useful; there has been some mail since then 18:06:32 I did a data science! 18:06:51 I wrote something today summarising where I think the discussion is; do others have thoughts on where it stands? 18:06:57 basically, I think the pathologial case is what is going to sway this. for the vast majority of cases it's fine to not compress 18:07:06 yes indeed 18:07:12 but at the large end, it's like... bad 18:07:14 v bad 18:07:32 and \exists workarounds for the tools that can't work with compressed symbols 18:07:45 so, I am leaning towards continuing to compress by default. 18:07:58 (as I emailed) 18:08:03 it's interesting how a certain number of years ago when we all had massive HDDs, disc space was rarely a good argument, but now we have smaller SSDs in many cases 18:08:13 it's sort of gone back the other way 18:08:28 well, our SSDs now are the size of our HDDs back then 18:08:40 there's also the VM case. I try not to assume a given install of Debian will have >16GB of space, and in some cases we might want to run as slim as 8 18:08:41 but our web browsers are bigger 18:08:45 see also raspis, etc. 18:08:48 I also lean towards continuing to compress. There could be also a threshold - Compress when size > x (but x would have to be defined and kept up to date) 18:09:04 gwolf: what exactly would a threshold achieve? 18:09:11 confusion :) 18:09:37 Yeah, a lot of confusion :) 18:09:46 very likely :) 18:10:04 I also don't like the idea -- And that would lead to getting into detailed design work 18:10:07 the debhelper maintainer specifically doesn't want an on/off switch via CLI, since that's more complex than either compressing or not compressing 18:10:17 I suspect the same argument rules out a threshold 18:10:18 smcv: ah thanks for reminding us of that 18:10:20 Particularly because debug symbols are not necessarily used in a vacuum. If you're trying to debug a KDE program, you might need to install debug symbols from tens of libraries and each package might be small, but the combination ends up being big. 18:10:31 smcv: has said it much more nicely than me 18:10:49 smcv is a good conveyer of truth :-] 18:10:52 it seems like we have a committee consensus, but do we want to allow doko more time to provide specific cases of non-build time tools which compression breaks? 18:10:58 doko or others* 18:11:16 they've had over a month now, right? 18:11:34 if they came back with more tools, would we change our minds? 18:11:40 I'm pretty sure I would not. 18:11:46 they're welcome to reopen the bug or open a new bug if they have new info? 18:11:51 ^ 18:12:00 I think we have given enough time for further arguments... 18:12:17 they are compressed atm right? 18:12:18 I am for closing the bug. Of course it can be reopened if needed. 18:12:22 and people are successfully debugging 18:12:23 spwhitton: correct 18:12:26 yes, they are compressed now. 18:12:28 I have only skimmed the bug, but I don't see any arguments saying which concrete problem with compression there are 18:12:30 okay then 18:12:39 so I think we can assign someone to close the bug 18:12:56 given that I already wrote a short summary today, I don't mind doing it, unless someone wants to 18:12:58 And also, if there are tools unable to handle the compressed data... the tool can be patched to do so 18:13:19 I volunteer smcv who has done a better job of words than me today, but spwhitton is also fine :) 18:13:30 smcv: willing? 18:13:37 sure, why not 18:13:42 * ehashman already did the number crunching 18:13:54 #action smcv to draft statement closing #976462 18:14:05 okay then, I think we can move on, thank you smcv 18:14:16 #topic Rescheduling monthly meetings 18:14:33 let's do this now so we definitely do it -- can we move to second Wednesdays? 18:14:41 yes 18:14:45 I can 18:14:48 wfm 18:14:49 yes 18:14:52 yes 18:14:59 the particularly wednesday doesn't matter. I will have a conflict once DST changes again :) 18:15:12 +1 18:15:17 ehashman: at that point it might be worth running a fresh poll 18:15:31 gwolf: how about you? 18:15:32 cool, I'll provide a meeting's worth of notice at that point 18:15:40 ehashman, you're talking about the next change, right, in October/November? 18:15:44 I can do it, yes 18:16:14 yeah 18:16:18 great 18:16:21 not for a while 18:16:30 then it is done, we will next meet 14th April 18:16:32 Right, I guess we can run a new poll around that time. 18:16:43 #topic Moving forward with our reimagining the TC tasks 18:17:02 the first thing that occurs to me with this topic is that it would be good to assign someone to the item that fil was previously assigned to 18:17:32 Can we review what the items were? I had something assigned, but I forget what (!) 18:17:40 yes let's do that 18:17:51 #1: allow to be invoked early (fil) 18:18:00 ahhh no 18:18:12 #1: private discussion: ehashman 18:18:17 #2: allow to be invoked early: fil 18:18:35 oh hey, we're finally not drowning in bugs 18:18:41 you can action me with #1 for next meeting 18:18:59 #3: explicitly delegate mediation: no driver 18:19:11 #4: design work: TC will not drive 18:19:20 #5: abolish TC: TC will not drive 18:19:40 #action ehashman to work on proposal #1 some more and report back to next meeting 18:20:18 two proposals in the air at once is probably sufficient unless someone particularly wants to work on #3, so do we have volunteers for #2? 18:20:53 I find it quite interesting so it could be me, but I do not have any very bright ideas about it. 18:21:35 which bits should I read up on? I'm seeing rethinking-the-tc/earlyinvocation.org but it doesn't have #1/2/3/4/5 18:21:48 Myon, that's what fil did before leaving 18:21:50 Myon: sorry, there is a file called rethinking-the-tc.md 18:22:02 under talks/ 18:22:11 ah confusing filenames 18:22:15 https://salsa.debian.org/debian/tech-ctte/-/blob/master/talks/rethinking-the-tc.md 18:22:24 ta 18:22:33 Maybe we should move that md to the other folder 18:22:45 I am too time-pressed right now, and I think it even shows in my lack of focus in interactions :-( 18:22:53 so I cannot offer myself to drive #3 18:23:28 marga: if it wasn't an actual talk, definitely 18:23:37 I think I might take a stab at the mediation body thing (#3) 18:23:42 it was a talk, so maybe we could symlink. 18:23:44 marga: oh, fantastic 18:24:04 #action marga to work on proposal #3 and share some ideas next meeting 18:24:17 well, in that case I am inclined to leave proposal #2 with no driver for now 18:25:25 Sure, we can use fil's basis. 18:25:44 if Myon is interested in working on it after getting himself up to speed, he can certainly do so 18:26:02 and I might take it up at our next meeting, depending on how concrete things get with the other two proposals 18:26:10 in that case, any other things on this topic? 18:26:16 I don't think I can drive something now, but I can certainly help out in some parts 18:26:31 cool 18:26:40 are these proposals all opposing, or orthogonal? 18:26:52 the ones we are actually planning to do are mostly orthogonal 18:27:00 that sounds like a smart plan 18:27:25 others were included for completeness but no-one outside the TC said they wanted to work on them, so we can pretty much forget about them, I think 18:27:36 Yeah 18:27:51 #topic Any other business 18:28:01 well, we already welcomed Myon and thanked marga 18:28:13 Nothing else from my side 18:28:15 but once again, welcome Myon, and thanks marga! 18:28:23 also thank you spwhitton for volunteering to chair 18:28:33 fwiw I believe Debian could use some body driving technical matters (no idea if the TC is the correct place, though) 18:28:36 no problem :) 18:28:43 And thanks Sean for volunteering! 18:28:49 Myon: you mean, design work? 18:29:21 yeah I guess that's a name for it, but that's more a feeling than an idea 18:29:33 okay 18:29:40 do you mean more like leadership and the defunct release-goals concept? 18:29:54 Well, there was this idea from a previous DPL of creating some kind of design committee 18:29:56 probably 18:30:08 was that the roadmap thing? 18:30:09 Myon: IMO, as design work often gets in the details of each specific problemspace, no project-wide body could come up with that 18:30:16 ...it has to come from the affected subregions 18:30:17 Yes, the roadmap thing. 18:30:36 do people want us to be the Fedora TC? is that the idea? 18:30:37 of course, some bits of the problemspace could be projectwide ;-) 18:30:38 I think there's a difference between detailed design and having a road map 18:30:49 if the project has a discussion about this sort of stuff then the TC has a lot of relevant experience 18:31:00 ehashman: I am not familiar enough with Fedora to sit in its TC ;-) 18:31:23 I think we are through with our official meeting however 18:31:28 #endmeeting