18:01:13 #startmeeting 18:01:13 Meeting started Tue Jun 14 18:01:13 2022 UTC. The chair is spwhitton. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:13 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:01:18 #topic Roll Call 18:01:20 Sean Whitton 18:01:31 Niko Tyni 18:01:46 Matthew Vernon 18:02:52 Helmut Grohne 18:03:11 Simon McVitti 18:03:12 Simon McVittie 18:04:59 Gunnar Wolf (although will disappear very soon) 18:06:46 #topic Review of previous meeting AIs 18:07:03 Emperor: would you like to report back 18:07:13 I've checked today, and there is no sign of our requested change having been made to util-linux 18:07:37 I would say we still have room before any freeze deadlines that we can just re-action you to keep track. 18:08:04 Maybe now I should ask for when the maintainer sees themself making the change? Or would you rather keep a watching brief for now? 18:08:34 We have a lot going on. I'd prefer to leave it. But others may disagree. 18:08:57 Would a polite question hurt in any way? We can wait another month for a reply 18:08:59 is there a util-linux bug open? 18:09:32 if so, perhaps "affects -1 tech-ctte" would help to keep it on our radar 18:09:53 there is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966468 18:09:56 there is 966468 18:10:19 Elana Hashman (late rollcall) 18:10:22 we could action Emperor to update that bug's metadata in general as sufficient for now 18:10:32 plus removing wontfix? 18:10:41 yes, I meant that too 18:11:18 should I adjust the priority too, or leave at wishlist for now? 18:11:39 I think adjust it though maybe not higher than normal 18:11:56 adjust to normal seems reasonable to me 18:12:10 okay, let's leave it to Emperor to adjust things 18:12:26 #action Emperor to continue to watch util-linux inc. updating #966468 metadata inc. severity 18:12:32 ehashman: any updates on private comms? 18:13:41 was on my todo list for yesterday and didn't get to it. I'm hoping this week because I'd like to get it out of the way and stop worrying about it :) 18:13:48 okay coolio 18:13:55 #action ehashman to commit private-comms slides+gobby to git procedures/ 18:14:07 ntyni completed his draft aside from a dscription of one bug 18:14:32 many thanks 18:14:38 yeah, the most controversial one I guess 18:14:46 it would be good to get this out, so one thing we could do is assign one person to fill in that missing bug (probs. ntyni) and one other preson to review, and if they are okay with it, ntyni mails it out. 18:14:53 would anyone like more oversight than that? 18:15:13 Sorry... 18:15:16 real life is biting 18:15:20 I should disappear now :-( 18:15:27 gwolf: see you! 18:15:30 ~~~ 18:15:31 o/ 18:15:39 wfm though I'd welcome help with the last one 18:15:50 spwhitton: seems reasonable; I had a quick look and made one pedantic edit 18:16:07 I can probably look it over as well 18:16:25 would someone like to be assigned to write the description for the final bug? 18:16:46 * spwhitton is relatively busy for next ~2w. 18:17:14 * Emperor is off on holiday from 22nd, and will be trying to stay offline 18:17:14 well I guess I should really finish it myself so never mind 18:17:17 I'm happy to proofread but I can't write it 18:17:18 ehashman: certainly welcome, do you also want to be the person to do the final review before ntyni sends it out? 18:17:46 uh sure you can make me the final reviewer 18:17:59 great, thanks for volunteering both of you, let me do some actioning: 18:18:03 cool thanks 18:18:07 #action ntyni to complete draft of bits mail 18:18:18 will try to finish it this week 18:18:19 #action ehashman to give a review and final okay to bits mail after ntyni has completed draft 18:18:29 #action ntyni to send out bits mail once ehashman has completed her review 18:18:50 #topic Bug#1007717 -- Native source package format with non-native version 18:18:57 I sent an updated ballot a few days ago. 18:19:14 oh, I haven't seen it yet then 18:19:42 the new ballot is an improvement but it's been an additional month without significant changes to the discussion, so I think we should consider voting 18:19:43 is 87h74vpvq1.fsf@athena.silentflame.com the latest? 18:19:51 https://lists.debian.org/msgid-search/87h74vpvq1.fsf@athena.silentflame.com 18:19:53 I think? 18:20:06 indeed 18:20:13 #link https://lists.debian.org/msgid-search/87h74vpvq1.fsf@athena.silentflame.com 18:20:30 I have tried to catch up on the thread, but it's a pretty big thread 18:21:03 smcv: I wrote a summary a while back, which might be useful 18:21:38 #link https://lists.debian.org/msgid-search/d1c397ec-999f-9d63-0d24-aa696f0af33c@debian.org 18:21:44 one thing that I don't think has explicitly been said is: I don't like 1.0 format because it's far too easy to accidentally upload the 1.0 (single tarball) sub-format when you had meant to upload the 1.0 (diff) sub-format 18:21:56 I'm not sure we need to accomodate each and every use case and continuing support for 1.0 (diff) has a measurable cost. 18:22:12 On the one hand, the thread is long and it is good for voters to have read all of it. On the other hand, it feels like we could just go on indefinitely extending it without things changing much. 18:22:33 I'm inclined to the view that we're at the point where voting would be useful, I don't think there are un-made compelling arguments in any direction 18:22:50 Emperor: right, the arguments have all been made, it's a question of people being caught up. 18:22:51 let me catch up and read the internal ballot before calling a vote 18:23:04 I continue to be behind on everything 18:23:22 ehashman: how long do you think that would take you? 18:23:27 I also have an increasing amount of sympathy for the packaging model in e.g. RPM and Arch, where literally everything has a revision number 18:23:44 spwhitton: give me a week at most 18:23:57 okay cool, so how about I actoin myself to star ta vote seven days from now? 18:24:01 and even their equivalents of things like base-files are just versioned 1.2.3-1, 1.3-1 ... or whatever 18:24:05 smcv: does that work for you? 18:24:07 I think there's essentially questions: a) native packages with dash versions and b) 1.0 diff usage. while I think not much can be said about a) anymore, b) is less obvious to me even after having read everything. it's a trade-off. 18:24:31 apropos ballot timing - I will be AFK from late 2022-06-22 until late on 2022-07-03 and would rather not miss a vote as a result 18:24:49 btw aiui the new process from https://www.debian.org/vote/2021/vote_003 means any TC member can request a two week delay after the initial call for votes 18:24:49 ah, so I could start it on Monday 20th? 18:25:15 or alternatively we just schedule it after emperor's trip 18:25:21 I could start it on 3rd. 18:25:27 spwhitton: 20th would be fine (unless something changes I think I know how I plan to vote) 18:25:39 spwhitton: happy with any vote timing 18:25:42 I would rather not delay things 18:25:57 ehashman: is 19th too early? 18:26:13 I'm taking vacation week of the 20th so no 18:26:20 will have to be done by then 18:26:47 I have a flight on the 19th so I would like to send it off, sen dmy vote and get on te plane 18:26:51 so let's do that 18:26:58 #action spwhitton to start vote on #1007717 on 19th 18:27:01 would someone opinionated about 1.0 diff try to convince me that we should keep it or could we add a "no 1.0 diff option" even if everyone else downvotes it? 18:27:23 helmut: that's "Option X -- issue only items 1, 2, 3 and 5" 18:27:53 Emperor: it's not. it lacks the statement that 1.0 diff should go away 18:28:37 helmut: I can add it if you want, or you can propose it yourself after the vote starts. 18:28:40 1.0 diff> briefly: it avoids having to keep debian/patches inside the package tree (or having to do a full upload incl. orig source each time) 18:28:47 former is probably easier for everyone. 18:28:53 Emperor: not within this meeting please ;) 18:28:57 OK 18:29:15 But at this point, it's probably easier just to have a "we should do away with 1.0 diff" option on the ballot 18:29:21 okay I'll add it 18:29:34 #action spwhitton to add option (E), we recommend doing away with 1.0+diff 18:29:52 #topic Do we want to start systematically announcing decisions to d-d-a right after we make them? 18:29:56 do we have any idea how many packages are using that format? 18:29:59 A few people have expressed some views on this already by mail, thank you fo rthis 18:30:07 ehashman: oops sorry. yes, there are stats in the thread. 18:30:11 ehashman: lintian classification tags would tell us I think 18:30:14 great, thanks 18:30:39 currently we do announcements pretty ad hoc 18:30:41 declaring an interest, I use it for my dgit-packaging-based things (which is more of my packages as time goes by) 18:31:02 spwhitton: I think announcing our decisions might be useful - it's not like we make so many as to amount to spamming the list 18:31:26 and we usually have some rationale in the ballot, so it's hopefully not a huge amount of work... 18:31:37 it's not a lot of work, no 18:31:45 the concern is that most of our decisions affect only a few maintainers. 18:31:51 and people really don't like getting a lot of d-d- amail. 18:32:09 I guess I have a vague worry that announcing the decisions but not when a bug comes to us initially risks people being annoyed that they were only told after the decision was already made 18:32:20 we could put a bit in the "bits from" suggesting it as an idea and see what folks think? 18:32:29 Emperor: oh, nice 18:32:39 yeah worth a try I guess 18:32:44 should we also consider surfacing when bugs are being considered by ctte? 18:33:00 (http://paste.debian.net/1244115/ 1.0 diff usage now) 18:33:01 people can just subscribe to our list, right? 18:33:23 that is not a good argument, actually. 18:33:26 yes, though they might want to just know what issues are being considered rather than the full firehose 18:33:29 yeah seems like we should consider doing both 18:33:34 yeah, that 18:33:35 let's put both in bits 18:33:43 someone like to write it? 18:33:47 other than ntyni maybe :) 18:34:00 my slight twitch is not wanting to have a "please come and join this month's flamewar"; I think some folk feel having the TC on their bug a bit intimidating already 18:34:29 mm 18:34:33 yeah, I am equally worried that we'll get a bunch of angry post-hoc interest on decisions 18:34:34 that is an asymmetry. 18:34:44 ah yes. 18:34:56 where people otherwise wouldn't have cared 18:35:18 maybe send both to d-d instead of d-d-a would be a middle ground 18:35:38 I think the past practice of announcing each decision on d-d-a was actually fine and worthy continuing 18:35:43 ntyni: it would be better on the spam front but doesn't really help with angry interest 18:35:50 sure 18:35:57 helmut: how long ago was that? are you sure? 18:36:08 one option would be that maybe we send a summary of all in-progress and closed bugs on a regular interval? like quarterly 18:36:10 I'm pretty sure we used to do it 18:36:31 subject match [CTTE #??????] ... 18:36:41 hmm ok 18:36:58 at least 20 mails like that 18:37:01 batching them might reduce the likelihood of any one particular bug becoming a lightning rod 18:37:07 from 2012 to 2016 at least 18:37:22 ehashman: it's more work as it's less automatic to crank them out at the right times, tho. 18:37:39 in 2017 and 2018 the subject pattern changed 18:37:39 intermediate with the annual summary that ntyni is currently working on, I guess 18:38:00 (still think let's put a bit in there asking what people would like) 18:38:05 do we really think that d-d-a receives too many mails? 18:38:08 Emperor: would you like to write it? 18:38:08 no 18:38:15 d-d-a is fine 18:38:35 helmut: I guess the thing is that people have d-d-a going to their top-level inboxes rather than lists subdirs 18:38:35 spwhitton: not really I'm snowed under, but I can try 18:38:46 Emperor: ah sure thing 18:38:56 anyone got some more time in next wek -- ideally this doesn't block ntyni sending it out 18:39:03 suggest if I've not done it before I go on holiday you a) send me hate-mail b) assign to someone else :) 18:39:43 I guess I can also try to fit it in, doesn't seem difficult 18:40:24 though I'm not sure where we want the opinions - d-d I guess 18:40:42 ntyni: we can just summarise a few of the ideas and see wht we get 18:40:50 yeah let's not overdo it 18:41:01 #action ntyni to add something simple to bits mail requesting input on announcing decisions 18:41:14 okay, anyone got anything they'd like to say? else we should move on to final, large topic 18:41:16 ntyni: would you like me to see if I have to draft something, or just leave it to you? 18:41:40 s/have/& time/ 18:41:48 maybe I'll ping you if I need help 18:41:53 ack 18:41:58 & thanks 18:42:50 #topic DebConf22 presentation 18:43:08 What do we want to have in our talk beyond the standard content, if anything? It's worth noting that it's meant to be a BoF, so, we want plenty of time for Q&A. 18:44:05 Also, who is now sure they'll be at DebConf? It would be good to put such a person in charge of this topic in general. 18:44:16 [definitely not going to be there] 18:44:16 debconf -> 95% 18:44:28 I definitely will not attend in person. I may be able to dial in virtually 18:44:33 same as ehashman 18:44:43 depends on time of day 18:44:51 not attending either 18:44:57 I am 50% 18:45:00 at least not in person 18:45:11 gwolf will be there 18:45:25 well at least there will be 2 18:45:28 so it's basically gunar and me, right? 18:45:42 helmut: dont' know about Myon 18:46:53 Myon said "maybe" earlier 18:47:04 okay, thanks. given this low attendance, I'd like to suggest that we do indeed just do a minimal talk like in years past, and then Q&A. 18:47:40 anyone have other thoughts on content? 18:48:01 that sounds good to me; 18:48:48 status update of the 'reworking CTTE' project? not sure how much there is to report though 18:48:55 I'm relatively busy ahead of debconf, because I'm going to prepare a talk and be busy with non-debian during debcamp 18:48:56 ntyni: it's finished aside from ehashman's AI. 18:49:02 right 18:49:16 ehehe 18:49:22 always happy to hold stuff up 18:49:34 let's not bring it up in talk except in Q&A 18:50:26 okay then, we need to prepare the slides. it's a relatively easy task because we have the old ones and we have ntyni's bits mail. so it's just a case of updating them. 18:50:44 honestly we could probably delay it untli next meeting. 18:50:50 but, if someone wants to get it done, that would be great. 18:51:14 #agreed minimal talk with lots of Q&A, old slides + contents of this year's bits mail 18:52:50 it would perhaps be reasonable to just do it at debcamp, really. 18:53:21 #info Next meeting we will need to assign someone to update the slides content and to lead the presentation if spwhitton isn't there. 18:53:43 we are coming up on an hour so let's leave this for now, unless anyone has anything to add 18:54:09 #topic Any Other Business 18:54:12 has anything come up? 18:55:33 [discussion in -ctte-private right now on something that's come up] 18:59:33 #endmeeting