14:59:36 #startmeeting 14:59:36 Meeting started Thu Nov 26 14:59:36 2020 UTC. The chair is h01ger. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:59:36 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:59:58 #topic 1. Say hi / review & amend agenda as needed - https://pad.riseup.net/p/lts-meeting-agenda 15:00:01 * utkarsh2102 waves o/ 15:00:06 o/ 15:00:06 * h01ger = Holger Levsen, hi 15:00:06 hi everybody 15:00:07 hello 15:00:13 Hi 15:00:26 * h01ger just added lts-do/not-call me to the agenda. i guess it will be a 2min topic 15:00:34 export TZ=UTC; echo Good afternoon 15:00:45 :) 15:00:49 ooh :) 15:01:50 * h01ger gives people 60 more seconds to show :) 15:02:59 #topic 2. frontdesk handling 15:03:46 * h01ger liked the mail thread. even though it started a bit heated, it then calmed down and became very productive 15:04:29 apo: especially your summary mail. i guess some bits of it are not documented (?) if so it would be good to add them to the existing docs 15:05:07 (btw, el_cubano remarked that he might miss todays meeting because of a local holiday) 15:05:22 yes, I can them to the docs. I just wanted to wait for the meeting if there is more feedback. I will post another draft before making it official 15:05:29 add 15:05:48 yes, today is Thanksgiving in the US 15:06:48 apo: cool. i wouldnt be surprised if someone only speaks up when the diff becomes visible in git (or half a year later), but this also means there's no use to wait for further feedback to the mail thread ;) 15:07:07 I do have something to say though 15:07:19 go 15:07:25 please speak up 15:07:26 I don't htink the frontdesk should add all vulnerable packages to dla-needed. 15:07:56 I man, when the frontdesk is triaging, if it's a clear no-dsa or ignored or postponed, they should do that 15:07:59 #action apo wil document/updates the current best practices for frontdesk handling per ml thread 15:08:31 otoh, if the other person feels that it is something that warrants a DLA instead, then just drop an email (public or private) and proceed with that. 15:08:48 I have outlined some guidelines but there is no hard rule. I just believe we should fix most CVE anyway and not just postpone them indefinitely 15:09:11 of course 15:09:35 but I feel the frontdesk could do the initial triaging, instead of adding everything to dla-needed 15:10:07 is that related to "lts frontdesk should not run ahead of triaging than the security team"? 15:10:08 there are some obvious CVE that can be ignored, devision by zero CVE for example but if front desk is in doubt about the severity, please add the package to dla-needed.txt with a note and another contributor should double-check it 15:10:29 for eg: if X marked ruby2.1 as no-dsa but me, being the part of the team and/or the maintainer feels that it is something needs a DLA, then I'd just drop an email and add it to dla-needed. 15:10:45 utkarsh2102: FD shall add a package to dla-needed if its CVEs are no-dsa and just send an email if a DLA is needed? 15:10:51 normally, we do not see a lot of such cases where the FD's opinion and the contributor's opinion differs 15:11:35 h01ger: no, not at all, it's not related. 15:11:43 utkarsh2102: but thats just 'maintainers opinion trumps anyone except tech-ctte'? 15:12:09 let me quote the part from the email, brb 15:12:41 (division by zero resulting a daemon crash is not be ignored, btw) 15:13:03 "No matter how front desk thinks about the vulnerability, add it to dla-needed.txt with a NOTE (optional) and document your assessment." 15:13:05 if you are the maintainer of ruby2.1, then in the ideal case FD has contacted you already by sending a bug report, you could react to it and say that you want to fix the package. If FD didn't send a bug report and you want to fix a package, then you can send an email to frontdesk to avoid any confusion. However that was my point in the first place, let's don't triage too many CVE as no-dsa and use 15:13:09 this is what I am reffering to. 15:13:11 dla-needed.txt for feedback instead of sending emails to each other 15:14:08 well fair enough, but not everything's worthy of going to dla-needed is what I am saying 15:14:24 * h01ger wonders if we can move on for now, let apo commit his improvements, which utkarsh2102 then can review and if he's unhappy we can continue discussion? 15:14:34 of course 15:14:42 there's not a lot of disagreement, really 15:14:49 yeah, let's do it this way 15:14:57 well, if we can resolve/clarify things now in 2min, that would also work :) 15:15:06 but, seems we move on :) 15:15:31 #topic 3. lts-do-call-me and lts-dont-call-me handling 15:15:34 I tend to be a +1/+0 on most of it, but just some small parts that I might be a -1. 15:15:45 but it's just me, I'll be happy to move on, of course! \o/ 15:15:52 this just came up on irc yesterday and several people couldnt find them 15:15:55 s/it's/if it's/ 15:15:59 so i just thought to mention 15:16:33 #info lts-do-call-me and lts-dont-call-me life at https://salsa.debian.org/security-tracker-team/security-tracker/-/tree/master/data/packages 15:16:46 not sure there's much more to say 15:16:51 btw I wanted to mention (though I am late) that the security team no longer has assigned people to front desk, and they seem to cope well, with a little coordination and shared responsibilities 15:17:10 pochu: interesting 15:17:29 #info for last topic: < pochu> btw I wanted to mention (though I am late) that the security team no longer has assigned people to front desk, and they seem to cope well, with a little coordination and shared responsibilities 15:17:38 anything else about our do and dont call lists? 15:18:13 using lts-do-call-me is fine 15:18:30 wfm 15:18:39 me too, indeed 15:19:41 #info this is documented in https://wiki.debian.org/LTS/Development#Contact_the_maintainer 15:19:47 so next topic then 15:20:10 #topic 4. project funding / finding projects 15:20:41 buxy said he couldnt join this meeting but wrote this in the agenda: "No opposition to the idea of project funding after the debian-project mail, but also nobody proposed any project. We should try to find ideas of projects that would help LTS and gather feedback from the corresponding team to see what they think of it. 15:20:43 https://lists.debian.org/debian-project/2020/11/msg00002.html (buxy)" 15:21:01 #save 15:21:58 * h01ger agrees with the idea but has no capacity to dive into this 15:23:10 I can think of three projects that may help LTS and Debian in general. 1. Making progress on the "bikeshed" project (PPAs), 2. Improve our testing capabilities, 3. Create something like lts-proposed-updates (2+3 could be combined) 15:23:33 I've got another in mind 15:23:47 ta: hey, would you or FTP team would be interested in handling #823820? 15:23:58 we keep hitting these and it's only going to get frequent 15:24:14 utkarsh2102: what do you mean with 'handling'? 15:24:23 I mean, here might not be the right place to ask the FTP team but just asking you in case you're interested or something? 15:25:24 h01ger: s/handling/taking care of as a funded project/g 15:25:29 utkarsh2102: ansgar wants to better sync all packages 15:25:40 that'd be great, really! 15:25:41 utkarsh2102: I talked to ansgar a while ago about that, and I think he had a solution thought for it (for another issue though, but the solution would also benefit this case) 15:26:29 aye, aye 15:26:31 great then 15:26:34 this is the only remaining real topic so we have some more minutes to discuss 15:27:04 I have another one 15:27:07 funded project definitly is something where someone can do more hours if they dont find enough work with fixing packages 15:28:05 In this regard, can you clarify how the 'Projects' line is handled in ELTS? 15:28:41 I noticed it the other day and couldn't figure out how it was provisionned, nor how it was meant to be used. 15:28:51 ? 15:30:21 (i dont really know/understand what you mean with that nor how/if its handled in LTS and so on) 15:30:35 extended-lts$ grep Projects:Available timekeeping.ledger 15:30:38 I think they are provisioned by 10% of the hours assigned each month, and they can be applied for by following the instructions in https://salsa.debian.org/freexian-team/project-funding 15:31:15 probably a separate topic 15:31:49 oh yeah, do we really take 10% off from elts hours as well? 15:31:59 for the same funding projects? 15:32:23 afaik yes 15:32:37 ah, okay 15:32:40 Beuc: thanks. both (in LTS and ELTS) are for funding projects like the ones in the topic 15:32:45 doesn't look like 10% and older 15:33:26 probably the unused hours are not accumulating (on purpose) 15:34:33 currently this question is a bit mood/off because hardly any of these hours are requested :) 15:36:00 so i guess we have no great ideas/plans on projects to fund and can move on the the last topics 15:36:05 ? 15:36:38 hey, should we kind of have a limit on where to stop saving the hours/money for funding projects? 15:36:53 Nothing to add to this topic here, although utkarsh2102's question is interesting 15:36:57 I mean, we have around 180+ hours of funding for projects. 15:37:02 but no projects to do, really 15:37:03 i dont think we are saving 15:37:10 apo had a few in mind 15:37:11 grep Projects:Available timekeeping.ledger 15:37:18 h01ger: there's been a few ideas floated around, but I think they need to be written down and sent to salsa 15:37:20 looks like we are not saving 15:37:35 pochu: ack 15:37:49 h01ger: I mean, that we do have a bunch of hours already and keep adding 10% each month 15:38:04 but since they're not being used, atm, should we probably dispatch them? 15:38:25 again: AIUI this is happening 15:38:48 like, let's say, the limit is 200. so once we have 200 hours for funding projects, should we start dispatching them for general LTS work 15:38:51 oh, is it? 15:38:57 no, it's not :p 15:38:58 I didn't know that. 15:39:02 they are dispatched to projects available and then they are not used, so dispatched again and again 15:39:08 ok, good 15:39:13 so next topic then :) 15:39:16 h01ger: they aren't dispatched to anything? 15:39:30 they are dispatched within the month 15:39:39 (as i read the ledger...!) 15:39:40 I think you're confusing Available with Projects:Available 15:39:49 yes, that's what I think as well 15:39:58 because we take away 10% every month 15:40:10 but we are not taking them anywhere the next month 15:40:35 Available is being dispatched. Projects:Available is not, and it's growing indefinitely because no projects are being funded yet (because nobody has proposed a project yet, and because we've been reserving time for a long time, and project funding was only announced / approved recently) 15:41:05 lts now has 27.0419h in Projects available, free to be taken. if they are taken fine, if they are not taken, they will be redispacthed again, probably to Projects:Available 15:41:48 Projects:Available is not growing (except by bits of hours over months) 15:42:11 sorry, I don't know where those 27h come from 15:42:31 anyhow, i feel this is leading nowhere now for most people so lets move on (happy to continue discussion after the meeting or via mail or whatever) 15:42:34 there's way more assigned to Projects:Available in LTS 15:42:58 #topic next meeting 15:42:59 but this is probably a question for buxy, so utkarsh2102, you may want to bring it up in the list 15:43:05 yes 15:43:11 #topic 5. next meeting 15:43:12 indeed, will do this weekend. 15:43:27 #info there will be no team meeting in december 2020 15:43:44 I have another topic, mom 15:43:54 #info the next lts team meeting is on Thursday, January 28th 2021, at 15 UTC on #debian-lts on irc.debian.org 15:43:57 that cound come in AOB^ 15:44:03 apo: what utkarsh2102 said 15:44:19 I have sent an email on Monday to our mailing list. "Fixing CVE in LTS and stable" 15:44:25 apo: please wait 15:44:37 in january we can also discuss what video meeting solution we want to use in february 15:44:54 #info in january we can also discuss what video meeting solution we want to use in february (and if we want video again) 15:44:59 #topic 6. any other business 15:45:05 apo: the stage is yours :) 15:45:17 I have sent an email on Monday to our mailing list. "Fixing CVE in LTS and stable" 15:45:41 whilst I do not do it all the time, I think it's definitely a good point. +1 to apo's mail :) 15:45:50 Do we agree that we should prepare DSA or point updates as well if the diff between LTS and stable is trivial ? 15:45:51 apo: our list is the public or private lts list? 15:46:00 the private list 15:46:16 apo: +1 15:46:32 apo: thanks i just found the mail 15:46:51 * h01ger agrees with the content of the mail but thinks it should have been sent to the public list :) 15:47:24 Does the security team & the maintainers actually wants this? 15:47:35 I had various success doing so. 15:47:48 Beuc: at least we can help with the point release updates 15:47:58 they're always looking for help 15:48:09 bin/lts-needs-forward-port.py lists a bunch of those which could need help 15:48:19 I can't imagine why the security team or the release team don't want bug fixes, but it is sensible to contact the maintainer to avoid any collisions or double work 15:48:25 Sometimes sec team just redoes everything without crediting and doesn't answer on how we can improve. 15:48:33 * h01ger still prefers if issues are fixed in sid and stable first, before fixing them in older releases (because sid and stable have more users) 15:48:35 and most of the CVEs have bugs opened against them, maybe sending a debdiff or asking first on the BTS would help 15:48:48 preparing a DSA does no hurt and the sec team decide whether to do the upload 15:49:01 right 15:49:13 yeah, though asking prior to do that would save a bit of time and effort :) 15:49:26 is this again something of documentation to be improved somewhere? 15:49:46 Beuc: i understand that sentiment wrt rails update but well, as I said, we can definitely help with point updates 15:49:49 could be something for LTS/Development 15:50:22 this can, though, be discussed once more publicly with security team explicitly CCed, so they can put in their opinions 15:50:32 that'd be helpful I think, to some extent, at least 15:51:05 utkarsh2102: can you kick that off? :) 15:51:31 h01ger: by all means, if apo doesn't have a problem 15:51:50 (since I'll be using most of his words probably) 15:51:54 no, not at all, then I concentrate on finishing the front desk guidelines 15:51:56 (with credits :)) 15:52:10 alrighty, will do this weekend then 15:52:22 we already have some guidelines btw here https://wiki.debian.org/LTS/Development#Guidelines_for_CVE_triaging 15:52:46 needs some clarification after I have finished the draft 15:53:12 \o/ 15:53:34 #action utkarsh2102 and apo will document "Fixing the same CVE in LTS and stable" as per our internal list 15:53:44 any *other* business? :) 15:54:36 wait, just to be on the same page, I'll initally send the private mail to public list (with security team CCed) + some other basic things to initate the discussion 15:54:45 and then we could document the conclusion 15:54:48 I created a new frontdesk file for 2021 by the way. (for both LTS and ELTS) 15:55:10 and surprisngly, all the slots are, more or less, taken :P 15:55:22 but lamby: thanks for doing that! \o/ 15:55:50 yeah, I wanted to send an email about that. if we're to keep FD, then others may want to jump in the train and we could evenly dispatch them if that's the case 15:56:02 lamby: cool 15:56:11 utkarsh2102: your page sounds good 15:56:16 I think I managed to not do LTS/ELTS around my birthday this year.. 15:56:24 lamby: *g* 15:56:53 OT: when's that? :) 15:57:13 so 15:57:23 lets wrap up the meeting 15:57:38 thank you all for attending and especially those with action items now! :) 15:57:49 o/ 15:57:54 o/ 15:57:59 o/ 15:58:02 o/ 15:58:15 o/ 15:58:20 ciao ciao 15:58:23 \o 15:58:30 #endmeeting