13:59:21 <h01ger> #startmeeting
13:59:21 <MeetBot> Meeting started Wed Apr 29 13:59:21 2020 UTC.  The chair is h01ger. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:59:21 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:59:35 <h01ger> so this is meetbot, its described on that wiki page
13:59:42 <h01ger> it will automatically provide logs
13:59:46 <h01ger> and a summary
13:59:59 <h01ger> anybody can add info to the summary by two means
14:00:04 <h01ger> https://example.org
14:00:13 <h01ger> #info h01ger gave a meetbot intro
14:00:16 <h01ger> #save
14:00:28 <h01ger> updates the log on meetbot.debian.net - handy if someone joins later etc
14:00:39 <h01ger> #topic introduction
14:01:02 <h01ger> I'm Holger from Hamburg, not really much affected by 'current events' currently. Please say hi to indicate p
14:01:03 <h01ger> resence.
14:01:18 <OlaLundqvist> hi
14:01:19 <ta> hi
14:01:21 <bunk> hi
14:01:22 <Beuc> hi
14:01:23 <daissi> hi
14:01:23 <el_cubano> hi
14:01:24 <apo> hi
14:01:26 <buxy> hi
14:01:26 <bhe[m]> Hello.
14:01:26 <utkarsh2102> hi
14:01:29 <gladk_> hi
14:01:32 <lamby> hi
14:02:05 <h01ger> about my job/role in LTS: I dont really see myself as your manager instead I try to be a secretary and offer advice. Often I ask buxy to decide (and just offer my advice to him as well). On average I spent less than 10h on billable work per month.
14:02:15 <h01ger> i thought this was useful information to you ;)
14:02:44 <h01ger> feel free to add other stuff you find important for this introduction, else i'll move to the next topic in 2min or so
14:02:47 <Beuc> :)
14:02:55 <h01ger> the agenda is at https://pad.riseup.net/p/ReLIIxDwtTkk_cuEuO_k btw
14:03:37 <OlaLundqvist> My work with LTS is as most others. I do typically spend most time on front desk. One of the reasons is the problem to find other work. This is a topic we will discuss later here I guess.
14:04:29 <buxy> For context, I run the business side, I used to be involved in the technical side at the start, but I stepped away because I have plenty of work with Kali mainly. I do still follow all the community side but less frequently than before.
14:05:15 <buxy> Hence the reason why I asked holger to fill the gap.
14:05:50 <h01ger> so, lets move on
14:05:57 <h01ger> #topic future meetings
14:06:55 <OlaLundqvist> Should we have some kind of poll now?
14:06:56 <h01ger> so, i think we need another poll, giving 7 days and 24h as options (every other hour..). and like the last poll we'll vote on the last week in May, meaning every last week of the month
14:07:29 <h01ger> thats about irc meetings and unless you come up with $something, i'll just go on with this plan ;)
14:07:59 <ta> sounds like a good plan to me    an please announce the poll :-)
14:08:04 <h01ger> sure
14:08:08 <lamby> Might involve a lot of clicking, but sounds good to me so that everyone's timetable/timezone is accommodated
14:08:24 <OlaLundqvist> Personally I'm more flexible odd weeks, because then I do not have kids but other times works fine too.
14:08:45 <h01ger> about video/voice meetings, i'd be happy to try them, and would go with video
14:08:59 * ta does not like video conferences
14:09:25 <h01ger> and unlike the irc meetings i would declare those meetings as 'paid lts team' private meetings. surely we can invite people occasionaly, but these could be our private meetings
14:09:30 <OlaLundqvist> Video do sometimes not work that well at long distances with lot of participants
14:09:36 <buxy> Time availability for me depends a lot of changing factors like my son's sport training and so on. So it might not always work out. Given enough advance notice, most people can arrange a bit.
14:09:53 <h01ger> buxy: do you see those video meetings as paid time as well?
14:10:00 <buxy> h01ger: yes
14:10:09 <daissi> would it be possible to have a summary for video meetings for people which cannot partipate?
14:10:27 <el_cubano> I don't mind video conference, but we should be sure to make good notes/records/logs for those who cannot participate synchronously to be able to review later.
14:10:37 <utkarsh2102> in that case, someone will have to volunteer for writing mom(s)
14:10:43 <h01ger> i suppose $someone can write logs
14:10:47 <OlaLundqvist> We can record the whole meeting if necessary. Not sure what tools we have available for that though.
14:11:02 <h01ger> it doesnt have to be volunteer as in non paid (the log writing part)
14:11:39 <buxy> video conf poses some challenges but with some rules, they work quite well, I'm ready to go with jitsi for a try, but if it doesn't work I'm also ready to use zoom or something that works
14:11:46 <h01ger> so, the #minidebconf-online folks are having a jitsi tests with their debian.social setup tonite, i'll see if that works
14:12:02 <buxy> FTR zoom can keep a record of the video
14:12:22 <daissi> there is also BigBlueButton
14:12:25 * h01ger would really prefer to stay away from zoom, TBH
14:12:46 * h01ger tries to conclude
14:13:23 <Beuc> I haven't checked zoom's licensing, I'll need to check that.
14:13:23 <h01ger> shall we aim for a video meeting in may already? or give other folks (#minidebconf-online takes place end of May) time to test first?
14:13:54 <buxy> #agreed videoconf are fine provided that we provides either a record or some minutes
14:13:58 <h01ger> i can provide a bunch of links about whats wrong with zoom, but thats off topic right now
14:13:58 <utkarsh2102> heh
14:14:04 <h01ger> also, doorbell, will be back in 2min
14:14:06 <h01ger> sorry
14:14:33 <OlaLundqvist> I think we can try already in May. If it does not work fine the first 15 minutes or so, we can fall back to IRC.
14:14:47 <buxy> Beuc: zoom is pretty much proprietary AFAIK, but as a participant, you can use it from the browser without installing anything
14:15:18 <h01ger> re
14:15:29 <Beuc> non-free JS I guess ;)
14:15:49 <h01ger> so, video meeting in May or June? i'm happy to do a similar poll for that one..
14:15:51 <Beuc> Do we want to plan a audio-only fallback in case bandwidth-issues, etc.?
14:15:58 <el_cubano> Or, if you have a smartphone that already runs a non-free OS, just install it to your phone.
14:16:10 <h01ger> Beuc: turning off video in jitsi is easy
14:16:17 <Beuc> ok
14:16:28 <ta> h01ger: I have no camer yet, so from my point of view: june
14:16:36 <bhe[m]> fallback option mumble :)
14:16:51 <h01ger> ta: you can join (jitsi) without a camera
14:16:55 <OlaLundqvist> My experience with more than a few participants is that video will not work that well. But screen sharing is usually very good and video from the person who currently speaks can be good.
14:17:10 <ta> ta: shouldn't it be a video conference?
14:17:35 <OlaLundqvist> I think voice and screen sharing is the most important. If we can get video working that is a bonus.
14:17:35 <h01ger> buxy: whats your opinion on May or June?
14:18:04 <buxy> I'm fine with May
14:18:07 * h01ger doesnt see how we need screen sharing but is curious to learn ($then) :)
14:18:25 <OlaLundqvist> Screen sharing is really useful when trying to explain something. :-)
14:18:33 <buxy> ta: no worries if you don't have any webcam yet, you'll see others at least but we won't see you
14:18:40 <h01ger> June would give us more time to let other sort out technical woes, but i'm fine to try in may
14:18:58 <h01ger> #agreed h01ger will do a poll for a video meeting using debian.social in May
14:19:02 <ta> buxy: that would be great :-)
14:19:03 <lamby> :)
14:19:17 <h01ger> #topic Sylvain suggests to discuss the relevance of the front desk role: see https://blog.beuc.net/posts/Debian_LTS_and_ELTS_-_March_2020/
14:19:54 <h01ger> "Most contributors claimed vulnerabilities by performing early CVE monitoring/triaging on their own, making me question the relevance of the Front-Desk role. It could be due to a transient combination of higher hours volume and lower open vulnerabilities." is the relevant sentence from that blog post
14:20:00 <h01ger> and Beuc is here too
14:20:03 <h01ger> :)
14:20:15 <utkarsh2102> Eh, my online classes seems to be working well with video conferencing. So it should be alright, hopefully.
14:20:50 <Beuc> h01ger, do you want to expand or is that clear enough?
14:21:02 <utkarsh2102> (sigh, I sent this 3 minutes ago :/)
14:21:03 <h01ger> Beuc: not sure. whats your suggestion to do/discuss
14:21:19 <buxy> Beuc: I think it's clear enough and utkarsh2102 raised something like this too
14:21:45 <utkarsh2102> yea
14:21:53 * h01ger thinks front-desk is (very) useful even if sometimes people are faster than frontdesk ;)
14:22:06 <OlaLundqvist> My opinion about the front desk role is that it is relevant and important to have someone that has the responsibility to do things.
14:22:23 <OlaLundqvist> A problem though is that it is rather often hard to find other work.
14:22:36 <Beuc> I don't have a clear suggestions, expect maybe poll what people feel about strengthening front-desk or weakening it
14:22:39 <OlaLundqvist> At least I have usually a problem to find packages that I can work with.
14:22:48 <daissi> I have the same problem
14:22:53 <el_cubano> For me, I usually see the automated commit emails from merges of the security-tracker into the ELTS repo.  If the suject mentions a package I'm interested in and I'm available, I'll check to see if it is in dla-needed.txt.  If not, I'll add it myself and start working on it.
14:22:54 <ta> frontdesk is not only about triage but should also answer questions from outside and take care of problems
14:23:05 <Beuc> I did some FD bypass in the past when FD was lagging (e.g. not working everyday), but only after 1-2d.
14:23:23 <buxy> IMO points 3-4 are tightly coupled and this results from the fact that we don't have enough work given the current funding level
14:23:39 <utkarsh2102> Beuc: seconded^
14:23:51 <h01ger> point 4 is "Sylvain suggests to discuss aggressive package claims, see https://lists.debian.org/debian-lts/2020/03/msg00043.html"
14:24:06 <buxy> and since people want to invoice all their hours, they look hard at getting updates assigned early, bypassing FD
14:24:09 <h01ger> is there a problem bypassing FD? i dont think so..
14:24:30 <h01ger> we document stuff in git, so, fine. or?
14:24:41 <Beuc> I have some arguments in 4
14:25:15 <utkarsh2102> h01ger: i've heard bypassing FD becomes problematic to the person at FD
14:25:18 <utkarsh2102> s/heard/seen/
14:25:23 <Beuc> Depends on whether bypass is within minutes of when a package is marked by security team, or a few days later
14:25:31 <h01ger> #topic Sylvain suggests to discuss the relevance of the front desk role: see https://blog.beuc.net/posts/Debian_LTS_and_ELTS_-_March_2020/ and suggests limiting concurrent claims in https://lists.debian.org/debian-lts/2020/03/msg00043.html
14:25:40 <h01ger> lets discuss this together than
14:25:51 <el_cubano> What about exploring some additional tasks (that do not directly involve packaing/fixing security vulns) to improve LTS, infrastrucure, etc.
14:25:52 <Beuc> depends on whether the claim is not while the claimer alreay has some work and should finish existing updates rather than claim more
14:25:54 <buxy> In theory, it's fine assuming that they do the same triage that FD would do. But in practice, they want to spend their hours and will favor handling the updates as opposed to marking it as no-dsa for example.
14:26:03 <Beuc> s/is not/is done/
14:26:06 <h01ger> i've now added checking for too many concurrent claims to my script preparing the semiautomatic unclaim mails
14:26:28 <h01ger> and set the limit to complain at to >=3 packages claimed
14:26:41 <buxy> So I would rather that people do not bypass FD unless the issue is really critical and a timely release is important, or if FD is unresponsive.
14:26:51 <el_cubano> buxy: That might be addressed by only permitting FD to list packages in dla-needed.txt and only allowing us to take packages already listed there.
14:27:09 <OlaLundqvist> Yes a rule that the person first check with front desk would be good.
14:27:21 <h01ger> el_cubano: or by enforcing not to bypass FD unless really critical
14:27:23 <lamby> Maximum number of claims and the role (or the "bypass") of FD feel like different topics to me. Shall we consider them one at a time? I don't think we got to resolution on the FD one.
14:27:31 <h01ger> so that two people principle
14:28:03 <OlaLundqvist> lamby/all: I think we can rather easily agree on that it is good that we have a front desk role.
14:28:32 <OlaLundqvist> The question is more about the interaction with that role.
14:28:36 <utkarsh2102> of course
14:28:37 <lamby> OlaLundqvist: Sure. I am talking about the bypass of FD too.
14:28:44 <h01ger> ok, lets split the topic again, to come to conclusions..
14:29:09 <h01ger> #topic rules on bypassing FD or not or exceptions
14:29:23 <h01ger> is that the question at hand?
14:29:29 <apo> FD is not only responsible for triaging but also for responding to emails on our mailing list and to IRC questions, so alone for this reason it makes sense to have such a role
14:29:48 <el_cubano> #agreed
14:29:49 <lamby> I believe at least twice I have gone to add something to dla-needed.txt as FD and it was already added simply in the 30 minutes I was spending on the triage and initial investigation of the issue. ie. a somewhat unavoidable race condition.
14:29:49 <h01ger> if so, i'd like to find a volunteer to update the README in git with the conclusion from this discussion here
14:29:50 <lamby> To be fair, it hasn't happened *loads* and I have been in LTS for some time so this might not even be an issue.
14:30:13 <h01ger> #agreed FD is not only responsible for triaging but also for responding to emails on our mailing list and to IRC questions, so alone for this reason it makes sense to have such a role
14:30:20 <utkarsh2102> I concur with buxy and would also add that we should have a "strict(er)" (virtual) rule to not let people triage packages themselves unless they're at FD!?
14:30:47 * ta agrees with utkarsh2102
14:30:51 <lamby> In the moment it is a little annoying to have wasted the time, but I understand that unless I am git pull'ing every 5 minutes whilst I'm investigating... it's fine.
14:30:59 <el_cubano> What about a script that automatically adds packages to dla-needed.txt with something like a [triage-required] tag?
14:31:29 <buxy> el_cubano: I don't see the point, what are you trying to solve?
14:31:50 <daissi> this will generates a lot of noise, no?
14:32:03 <ta> we are not the only user of that repository, the security might not like so many commits
14:32:14 <OlaLundqvist> I think so too. The lts-cve-triage script is good enough for that.
14:32:17 <el_cubano> It would make both the FD triage (or non-FD triage) and the packaging work itself "documented" in one place.
14:32:25 <Beuc> I'd say redundant with bin/lts-cve-triage.py
14:32:30 <OlaLundqvist> agree
14:32:31 <el_cubano> But the objections are noted.
14:32:36 <OlaLundqvist> :-)
14:32:45 <h01ger> #agreed people should not bypass FD unless the issue is really critical and a timely release is important, or if FD is unresponsive (for more than 24-48h)
14:32:54 <buxy> lamby: I'm not to worried about wasting a bit of time on the frontdesk side, but I'm worried about low quality triage because someone wanted to have work to do on an update they felt confident to handle
14:33:30 <h01ger> #agreed people should not triage packages themselves unless they're at FD
14:33:34 <OlaLundqvist> buxy: Agree. Let us discuss this a little on point 7.
14:33:50 <Beuc> buxy, I don't understand your remark
14:34:14 <h01ger> is there any volunteer to update the README with those agreements? else i'll do (but i'd prefer if you take this work away from me). and anyway i suggest to move on to the next topic, concurrent claims
14:34:29 <h01ger> or is there something still to be discussed about this topic? (FD)
14:34:36 <OlaLundqvist> I can volonteer on this.
14:34:39 <gladk_> I am very new here and have a question. Should every DLA always go through dla-needed.txt-file?
14:34:51 <h01ger> gladk_: please ask that question later
14:35:36 <h01ger> OlaLundqvist: yay
14:35:41 <h01ger> OlaLundqvist: thank you!
14:35:55 <h01ger> #info OlaLundqvist will update the README with the conclusions from the FD topic
14:36:05 <buxy> Beuc: FD has paid time to do "triage", other contributors have paid time to provide updates. For an untriaged CVE-XXXX, a contributor will decide to a DLA to spend his work hours while FD would decide no-dsa...
14:36:28 <Beuc> ok
14:36:47 <h01ger> gladk_: the answer to your question is 'yes'. for the reasons buxy just gave :) (and also to claim a DLA technically)
14:36:59 <Beuc> buxy, though FD can auto-claim and do both ;)
14:37:01 <h01ger> next topic?
14:37:13 <OlaLundqvist> Should we also have a rule that FD should not claim the package on his own?
14:37:47 <Beuc> should be OK with not-too-many-claims?
14:38:34 <h01ger> ok, lets move on. OlaLundqvist, i think FD should also be sensible with claiming packages ;)
14:38:37 <h01ger> #topic concurrent package claims
14:38:46 <h01ger> https://lists.debian.org/debian-lts/2020/03/msg00043.html
14:38:50 <h01ger> was the trigger
14:39:14 <h01ger> i'll now warn (in my weekly semi aytomatic mails) if someone has claimed 3 or more packages
14:39:34 <h01ger> we could also forbid 4 or X packages claimed
14:39:35 <OlaLundqvist> Should the limit be different depending on how many hours you have free?
14:39:44 <h01ger> OlaLundqvist: i dont think so
14:40:11 <h01ger> basically you should not have claimed packages you dont work on
14:40:23 <utkarsh2102> OlaLundqvist: I don't think so either
14:40:25 <buxy> For me concurrent package claims is fine, you often have to interact with others to properly handle a given update. The only problem is claims where nothing is happening and that should already be taken care of with the requirement to update the dla-needed.txt with status data.
14:40:27 <OlaLundqvist> I think we should have a limit. If the person is waiting for something it can be un-claimed with a note what is waited for
14:40:58 <utkarsh2102> Should there be a maximum limit? If so, should it be 3? Or lesser?
14:41:00 <OlaLundqvist> buxy: But you are right, some parallelism is good
14:41:02 <h01ger> all that is why i concluded to warn only... :)
14:41:37 <h01ger> i surely expect pochu to say 'i claimed firefox and thunderbird and X and am waiting because of foo' ;) (and i expect to reply 'fine')
14:41:38 <OlaLundqvist> I think a warning is fair enough.
14:41:49 <Beuc> I think # of claim is an inappropriate metric to regulate pre-emptive claims
14:41:49 <buxy> OlaLundqvist: what for? this is busy work assuming that the person is reactive when they get the answer they wanted
14:41:55 <Beuc> but I don't have another one ;)
14:42:42 <buxy> For me people are complaining of concurrent claims because they are not able to spend their work hours and the response to this is to have more work to do...
14:42:53 <OlaLundqvist> Well sometimes someone is waiting for an answer that someone else can solve easily.
14:43:19 <OlaLundqvist> But yes, I agree on that the problem is that we have too little issues to fix. :-)
14:43:28 <OlaLundqvist> Oh my we are overfunded. :-D
14:43:30 <buxy> We have some documentation on what other work you are allowed to do but few of you are doing anything else than preparing updates. We should likely try to be better structured to always have a list of other things to do...
14:43:33 <h01ger> i'd suggest i'll continue with issuing these warnings and we'll see how it goes in a month or two. and move to next topic now
14:43:56 <el_cubano> buxy: Perhaps we should put some effort toward organizing that list, ensuring new items are added to it, etc.
14:44:00 <OlaLundqvist> h01ger: Sounds like a fair thing to agree on
14:44:14 <h01ger> el_cubano: there is https://wiki.debian.org/LTS/TODO - please contribute
14:44:24 <el_cubano> h01ger: I'll volunteer to undertake that in the next days, if you and buxy agree
14:44:29 <buxy> el_cubano: definitely, I would love to have a list of packages that had security updates and that lack autopkgtest for instance
14:44:41 <h01ger> #agreed h01ger will continue with issuing these warnings and we'll see how it goes in a month or two
14:44:46 <h01ger> el_cubano: sure
14:45:04 <h01ger> #topic Raphael want to discuss the issue of putting LTS hours aside for other projects
14:45:04 <daissi> is it fine to write a DEP-8 tests for packages not supported by sponsors?
14:45:35 <apo> I would also like to suggest that we let team members who are also maintainers of CVE affected packages handle their packages. I find it inefficient when other people handle it
14:45:39 <OlaLundqvist> dassi: I think this question is a topic on its own
14:45:42 <buxy> daissi: as long as they have an history of security updates, I'd say yes
14:45:58 <daissi> thanks
14:46:12 <h01ger> the new topic is "Raphael want to discuss the issue of putting LTS hours aside for other projects. i.e. development projects that would improve the infrastructure and see what would be acceptable to everybody. Could this money reserve be spent to pay a developer not involved in LTS? How would we select projects? Should I select project? do we want a collective process? etc. Some of our problems are due
14:46:12 <h01ger> to contributors having too much time to spend on non-serious issues, we could thus vary the percentage of hours assigned to extra projects to ensure some scarcity and avoid the problems we have."
14:47:08 <h01ger> buxy: ?
14:47:12 <buxy> This is somewhat related to the current suggestion to have more things to do.
14:47:29 <h01ger> what do you want to discuss here+now?
14:47:32 <el_cubano> That may become easier to manage if the LTS/TODO list grows in an organized and manageable way.
14:47:48 <h01ger> el_cubano: yes :)
14:47:56 <ta> we should do the things on our own, I don't think external developers are needed for this
14:48:01 <buxy> Except that some things that we can imagine, like having a staging repository where tests are run and reports are generated, are huge projects, unlike adding DEP-8 tests to a source package.
14:48:29 <OlaLundqvist> buxy and h01ger: When it comes to other things in the TODO list, do we need to get some approval before it is started?
14:48:29 <buxy> So if we want those to happen, we need somehow to put money aside and spent it on larger chunk...
14:49:01 <h01ger> OlaLundqvist: depends on the amount of work. for a 2h thing not, for 20h yes
14:49:10 <Beuc> buxy, do you have a status of what was attempted/done last summer, when there was discussion of doing such infrastructure work?
14:49:14 <el_cubano> I would suggest allowing LTS contributors to first make a proposal for any large task before seeking outside developers.
14:49:23 <Beuc> it would help see what worked / didn't work
14:49:31 <h01ger> OlaLundqvist: i'm watching the diffs of that TODO wiki page, so...
14:50:10 <buxy> Beuc: I'm not quite sure what you are referring to...
14:50:17 <OlaLundqvist> I can add this information to the README when updating it. That it is ok to spend one or a few hours per month on other things in the TODO list but more than that needs approval
14:50:36 <h01ger> OlaLundqvist: i'm pretty sure its already in there
14:50:36 <Beuc> buxy, the work about a django app to run auto-tests, debusine, etc.
14:51:17 <buxy> Beuc: Right, basically it didn't go far due to lack of time on my part.
14:51:22 <OlaLundqvist> Ok it says 20-25% fair
14:52:24 <buxy> el_cubano: and then if we get multiple proposals, who gets to decide? what factors do we use to evaluate the proposal?
14:52:34 <h01ger> buxy: TBH i'm a bit lost where we are discussing this topic. eg more to discuss? action items? put on the agenda for next month again?
14:53:23 * h01ger reminds everyone that these meeting should last an hour and that i will cut it at 90min.
14:53:50 <buxy> yes, let's first answer the basic question. Would you agree if starting from next month, we put 10% aside to be used later in funding a larger infrastructure project?
14:54:03 <OlaLundqvist> I agree
14:54:17 <el_cubano> buxy: Since it's a business decision, I assumed you decide, perhaps with input from h01ger
14:54:27 <ta> if a project is to big to finish in a few hours, it can be broken into smaller chunks ...
14:54:47 * ta agrees to 10%
14:54:58 * el_cubano also agrees
14:55:06 <apo> +1
14:55:07 * h01ger agrees thats sensible. we spent some time doing updates others wouldnt do, so clearly we have too much time
14:55:16 <buxy> ta: yes if you have a project manager doing that work...
14:55:27 <daissi> I agree
14:55:29 <ta> buxy: we have h01ger :-)
14:55:36 <Beuc> h01ger, or others have too little time :)
14:55:47 <h01ger> #agreed starting from next month, we put 10% aside to be used later in funding a larger infrastructure project
14:56:12 * bhe[m] also agree
14:56:16 <ta> otherwise the person making a proposal could do this as well
14:56:28 <h01ger> buxy: anything else to discuss now? or continue this discussion next month?
14:56:29 <utkarsh2102> me too
14:57:19 <lamby> Sounds good.
14:57:45 <OlaLundqvist> Please continue.
14:57:56 <OlaLundqvist> Looks like discussion stopped.
14:58:08 <buxy> Timing is almost over.
14:58:24 <buxy> I'd like to have holger's update on the LTS survey.
14:58:29 <h01ger> well, we agreed to do 90min today max, because this is the first time
14:58:31 <h01ger> so
14:58:35 <buxy> Ah ok, right.
14:58:40 <h01ger> #agreed we continue this discussion next month
14:58:58 <h01ger> #topic create an LTS survey - contributors wanted
14:59:34 <h01ger> i didnt make any progress on this so far, and only (and at least!) utkarsh2102 said he wanted to help
15:00:22 <h01ger> my plan is now to find a date with utkarsh2102 next week to actually write up this survey, then survey the internal lts list whether the survey is sound, and then announce it to the world
15:00:23 <el_cubano> I must have missed the discussion.  What is the nature of the survey?
15:00:28 <ta> hmm, I seem to have missed something: what is a LTS survey?
15:00:30 <utkarsh2102> \o/
15:00:44 * ta is not alone :-)
15:00:50 <daissi> same here :-)
15:01:08 <h01ger> el_cubano: whats working well with lts, whats working not so well, wishlist bugs etc. - LTS is 6 years old now and we have no systematic understanding what people (dis)like about it
15:01:18 <h01ger> ta: daissi: ^
15:01:18 * el_cubano nods
15:01:23 <ta> ah, ok
15:01:31 <daissi> ok
15:01:31 <h01ger> we discussed this on the list some 6 weeks ago or so
15:01:47 <h01ger> so, any other volunteers? please ping me
15:01:58 <buxy> h01ger: is that also a mean to get feedback from the security team?
15:02:08 <h01ger> yes
15:02:12 <el_cubano> I'll go find the discussion and follow-up after reviewing the details.
15:02:25 <h01ger> buxy: and release team, and ftp team, bugs owner
15:03:18 <buxy> is restricted to other teams or do you expect users to respond too?
15:03:25 <h01ger> #info this should be a survey whats working well with lts, whats working not so well, wishlist bugs etc. - LTS is 6 years old now and we have no systematic understanding what people (dis)like about it. target audience for the survey are sponsors, non sponsoring lts users, fellow debian developers, esp security team, ftp team, bts owners, etc
15:03:40 <h01ger> buxy: its open to all
15:03:43 <buxy> ok
15:04:02 <h01ger> ok, next topic then
15:04:10 <lamby> :)
15:04:13 <h01ger> #topic Ola wants to discuss triaging practices and how to judge different type of packages
15:04:34 <h01ger> i recall jmm wrote something about this
15:05:21 <OlaLundqvist> One problem is that this may affect the "normal" debian security team so maybe they should be involved in this discussion too.
15:06:19 <h01ger> (i'd just call them the debian security team, as thats what they are and what they call themselves. we are the LTS team, easy enough distinction :)
15:06:30 <OlaLundqvist> :-)
15:06:31 <Beuc> a quick note about "(it is sometimes a little odd to see that LTS get updated while the regular security team judge it as no dsa with comment "Minor issue")":
15:07:32 <ta> no-dsa does not mean that this package gets no update
15:07:36 <apo> I think we can have a different opinion sometimes, they use "Minor issue" fairly often
15:07:56 <ta> if enough no-dsa are accumulated an update might be appropriate
15:08:03 <Beuc> security team do the triaging and doesn't do most uploads - packagers do. So when they mark "no-dsa" it's basically up to maintainer to do an update nonetheless, or do it in a point release. We do the triaging and the uploads, so we can make a more precise decision.
15:08:31 <daissi> When triaging, should we consider the fact that a package is in the packages-to-support list?
15:08:35 <h01ger> i think we should try not to have a different opinion than the debian security team.
15:08:48 <el_cubano> +1
15:09:01 <Beuc> h01ger, it's not a different opinion, it's a matter of delay
15:09:10 <h01ger> (we might to a DLA where they dont do a DSA, but the severity/impact should ideally have the same assessment)
15:09:17 <ta> daissi: such packages should be updated first
15:09:19 <h01ger> Beuc: i know :)
15:09:27 <OlaLundqvist> I think that, generally, we should have same opinion as debian secruity team. However it is quite often so that LTS front desk do triaging first.
15:09:29 <el_cubano> Also, perhaps one of the FD duties should involve reviewing packages with accumulated no-dsa entries to determine if an update is needed for LTS.
15:09:39 <el_cubano> Especially, since there are no LTS point releases.
15:09:42 <lamby> h01ger: Just found it, in the "security upload imposing load on other parts of Debian" thread which links to https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory
15:09:58 <h01ger> lamby: thanks
15:10:06 <h01ger> #info https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory
15:10:08 <el_cubano> lamby: Thanks.  I was looking for that in the lxc thread and couldn't locate it.
15:10:08 <lamby> #link https://lists.debian.org/debian-lts/2020/03/msg00013.html
15:10:08 <daissi> ta: ok
15:10:16 <lamby> h01ger: *g*
15:10:20 <lamby> #info https://lists.debian.org/debian-lts/2020/03/msg00013.html
15:10:39 <h01ger> OlaLundqvist: ^ if you could add this link to the README while at it... that would be much appreciated ;)
15:10:48 <h01ger> (the security.d.o link)
15:10:58 <OlaLundqvist> If an issue has been classified as minor should mean that it is not really that important to fix it. Would it change if we have many such?
15:11:08 <OlaLundqvist> holger: will do
15:11:11 * h01ger would like to close this topic, we still have 3 more and 18min left and 2 of the upcoming topics are also larger
15:11:15 <h01ger> OlaLundqvist: thank you!
15:11:27 <OlaLundqvist> Sore we can continue discussing next month
15:11:35 <OlaLundqvist> s/Sore/Sure/
15:11:52 <Beuc> We can discuss this on the mailing list too if you've got questions.
15:12:02 <h01ger> if we can move this to the list, i think this would be better
15:12:09 <Beuc> Let's not discuss EVERYTHING in the next meeting ;)
15:12:11 <h01ger> else next months meeting agenda will be very long again
15:12:13 <h01ger> that
15:12:27 <OlaLundqvist> I'll start a mail thread about this.
15:12:27 <h01ger> Beuc: can you move this discussion to the list?
15:12:28 <Beuc> haha
15:12:39 <h01ger> OlaLundqvist: 👍
15:12:53 <h01ger> #topic Roberto wants to discuss embargoed issues
15:12:57 <Beuc> OK. I have some material to copy/paste already.
15:13:07 <h01ger> "Roberto wants to discuss embargoed issues in order to understand proper etiquette around handling of embargoed issues.  Apparently, we have an LTS embargo team and there are issues being handled outside the view of other LTS contributors.  As we contributors become more aggressive in self-triaging, this has the potential to cause some problems."
15:13:26 <h01ger> as far as i know, we dont get informed about embargoed issues. end of the story.
15:13:35 <buxy> not true
15:13:35 <h01ger> please correct me if wrong :)
15:13:46 <el_cubano> h01ger: ta mentioned to me that he is part of the LTS embargo team
15:13:52 <h01ger> oh
15:13:52 <el_cubano> It made me think we had such a team
15:14:16 * h01ger stands corrected and waves with his fool hat
15:14:21 <buxy> We have an emails with ta and bwh on it. And the security team can copy them with information about embargoed security updates.
15:14:23 <ta> yep, we sometimes get infomations about embargoed issues
15:14:45 <ta> this happens about two or three times a year
15:14:56 <h01ger> #info there's an LTS embargoed issues alias with ta and bwh on it
15:15:03 <el_cubano> ta: So, perhaps not often enough to worry about.
15:15:13 <h01ger> el_cubano: i think so
15:15:14 <buxy> #info https://wiki.debian.org/LTS/Contact#Email_alias_for_private_exchanges
15:15:20 <h01ger> next topic?
15:15:31 <ta> el_cubano: yes
15:15:38 <el_cubano> h01ger: yes, please
15:15:42 <h01ger> #topic new upstream versions - our policy
15:16:01 <h01ger> i think our policy for new upstream versions should be the same as for stable / normal security updates
15:16:17 <OlaLundqvist> Yes almost
15:16:24 <h01ger> (so frowned upon in general)
15:16:34 <h01ger> OlaLundqvist: where do you see deviations?
15:16:42 <OlaLundqvist> Some packages (like spamassassin) need more regular updates.
15:16:49 <h01ger> OlaLundqvist: same in stable
15:16:59 <OlaLundqvist> That is handled in (previously named) volatile. Or is that part of stable now?
15:17:09 <h01ger> OlaLundqvist: yes. its called stable-updates
15:17:27 <utkarsh2102> yep. I wouldn't want to introduce a new upstream version unless very critical
15:17:35 <OlaLundqvist> Ok, so we have same policy as stable security and stable updates
15:17:40 <h01ger> stable/updates are security updates while stable-updates is what used to be called volatile
15:17:55 <buxy> There might be cases where it makes sense.
15:17:55 <el_cubano> No chance of confusion there /s
15:18:03 <h01ger> el_cubano: *g*
15:18:13 * bhe[m] looking for the security team's policy on new upstream version.
15:18:14 <lamby> (Does non-LTS security update firefox to new upstream versions?)
15:18:22 <h01ger> lamby: yes
15:18:30 <buxy> I mean when some packages are no longer supported and no longer supportable, switching to a new upstream version might be better than saying EOL.
15:18:41 <el_cubano> yes, along with openjdk, mysql (when it was in stable), t-bird, and a few others
15:18:48 <OlaLundqvist> There can be exceptions when we are forced to go for an upstream version because upstream have ceased its support.
15:18:56 <OlaLundqvist> exactly.
15:19:03 <bunk> buxy: An upper limit is in any case that the version has to be < than what is in the next stable release.
15:19:11 <h01ger> i dont think we should go for new upstream versions if stable didnt do that
15:19:34 <OlaLundqvist> But generally we should be as relaxed as the combination of stable/updates and stable-updates combined.
15:19:43 <buxy> In particular if you think that you want to continue to provide updates in Extended LTS...
15:19:47 <h01ger> eg something which is not updated to a new upstream version now should not get a new upstream version in 2 months when stretch becomes LTS
15:19:49 <buxy> bunk: yes
15:20:02 <h01ger> for eLTS i see things more relaxed than for LTS
15:20:30 <lamby> Was this issue raised because there is a package that we are unsure about, or was it more of a general enquiry? I wouldn't want the former question to be lost.
15:20:36 * OlaLundqvist conclude that all people seems to agree.
15:20:50 <buxy> but if you declare some packages EOF during the LTS timeframe because you refused to jump to a new uptsream version, it doesn't make sense to reintroduce support later either
15:20:51 <h01ger> #info we need to discuss and document deviations from that general rule though
15:21:19 <h01ger> time is just out in 8min and we have another topic left
15:21:28 <OlaLundqvist> Please go to next topic.
15:21:32 <h01ger> and personally i feel to rushed
15:21:36 <Beuc> Usually deviations are case-by-case and discussed on ML.
15:21:42 <h01ger> if someone wants to shift this discussion to the list, please do
15:21:47 <OlaLundqvist> Should I document something in README?
15:21:56 <h01ger> else we can let it rest here
15:22:06 <OlaLundqvist> But we can take it off the meeting. Please contine with next topic.
15:22:17 <h01ger> OlaLundqvist: maybe 'general rule' as discussed above and 'please discuss exceptions on the list first'
15:22:23 <OlaLundqvist> Will do
15:22:26 <h01ger> superb
15:22:33 <h01ger> #topic any other business
15:23:10 <h01ger> one suggested topic is 'yearly LTS sprints', which i think is a great idea, but which i also think we can postpone discussing at least as long as some of us are not allowed to leave their houses...
15:23:40 * utkarsh2102 nods
15:23:44 <Beuc> on-site sprints then?
15:23:45 <OlaLundqvist> Haha, yes we can postpone this topic when it becomes more relevant.
15:23:49 <h01ger> #info yearly LTS sprints: we should do them, once its practical again to do them
15:23:50 <ta> apropos nothing to do: while doing FD last week I stumbled upon CVEs that are marked as no-dsa for Jessie but are fixed in Wheezy and Stretch. As they are even fixed in Stretch, the no-dsa rating might not be correct anymmore. I would suggest to work on such packages as well ...
15:23:55 <h01ger> any other business
15:24:20 <el_cubano> Since I missed tagging this earlier:
15:24:21 <el_cubano> #action el_cubano (Roberto) to review/improve/updated/expand https://wiki.debian.org/LTS/TODO
15:24:24 <buxy> what's the idea of the sprint? meet IRL or work together for longer online?
15:25:04 <h01ger> a sprint before the debian-sprint before fosdem 2021 could work. or after fosdem. or at another time.
15:25:06 <utkarsh2102> (and maybe the big project you were discussing earlier)
15:25:07 <el_cubano> The sprints might good for at least the initial phases of larger tasks; in person or online would work
15:25:52 <h01ger> we could do a sprint at the minidebconf-online end of May
15:26:23 <h01ger> we also will end this meeting in 3min :) so if you have anything else to comment... do it now :)
15:26:38 <Beuc> Related to #5 / 10%-for-tasks then?
15:26:45 <lamby> Nothing here, beyond thanks for organising this. I enjoyed it and feel more connected to the rest of the team. :)
15:26:46 <h01ger> Beuc: ?
15:26:46 <OlaLundqvist> Looks like we do not have the time to finish this topic.
15:27:02 <OlaLundqvist> Yes really good that we have this meeting.
15:27:25 <Beuc> h01ger, sprint -> larger tasks -> topic #5
15:27:35 * h01ger is also happy how this meeting worked out
15:27:40 <h01ger> Beuc: ah
15:28:25 * buxy .oO (we need to put another 10% aside to fund travel for sprints !?)
15:28:52 <Beuc> That was not what I had in mind.
15:29:05 <h01ger> Beuc: i'd also see it as an opportunity to work together on other (LTS and other debian) tasks and to get to know each other better (which will improve working together later)
15:29:19 <h01ger> buxy: heh, touche!
15:29:31 <h01ger> so, thank you all for attending!
15:29:32 <buxy> Beuc: I know, but that's what in my head, while I like the idea of sprints, I'm not sure we can afford them.
15:29:40 <h01ger> o/
15:29:43 <Beuc> o/
15:29:47 <gladk_> thank you
15:29:48 <buxy> thanks h01ger, well done
15:29:54 <ta> byebye everybody
15:29:58 <OlaLundqvist> See you o/
15:29:58 <daissi> thanks h01ger
15:30:04 * utkarsh2102 hopes everyone is doing well and keeping themselves safe
15:30:18 <h01ger> #endmeeting