13:59:03 <buxy> #startmeeting
13:59:03 <MeetBot> Meeting started Thu Nov 24 13:59:03 2022 UTC.  The chair is buxy. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:59:03 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:59:15 <buxy> #topic Who is here?
13:59:22 <bhe[m]> hello.
13:59:24 <tumbleweed> hi
13:59:31 <buxy> hi
13:59:33 <utkarsh2102> hey!
13:59:35 <guilhem> o/
13:59:52 <Beuc> hi
14:01:04 <buxy> #topic Why are some packages for so long in the queue(s)? Why are LTS and ELTS queues growing?
14:01:05 <helmut> Helmut Grohne
14:01:25 <bwh> Hi, sorry I'm late
14:02:14 <buxy> First topic is a recurring concern for a few months, we have currently 82 packages in dla-needed.txt and a significant number of them have been there for multiple weeks (if not months).
14:02:15 <utkarsh2102> I have two points on the topic, I think. At least they apply to me.
14:03:20 <buxy> We probably can't do a full analysis right now but this is something where we need to question ourselves, and possibly make changes to our processes because the net result is not very good.
14:04:18 <helmut> I observe that quite a number of CVEs that I fixed during nov and oct ar fairly old.
14:04:19 <buxy> I'm too far from the work to have any valid opinion but I know that there are unused hours so it's not strictly a question of missing funding.
14:04:23 <bwh> Personally, I've been limiting myself to kernel packages, but I could start looking at other packages. I hadn't noticed that there were so many packages there
14:05:17 <utkarsh2102> First, a bunch of packages have a lotttt of number of CVEs (more than 10 at least) and it’s sometimes annoying. Reason for so many pending CVEs is that the said packages never received an update in buster so everything’s postponed and now piled up. I wanted to propose this earlier (but never got around to doing that) - can we do the fixes in 2 rounds, instead of 1?
14:05:39 <buxy> bwh: if you can increase your work time to cope with both the kernel and some other packages, it would be great yes
14:06:03 <utkarsh2102> You might wonder what’s the benefit, given it’s the same amount of work. But it’s slightly different. I can explain more if needed be.
14:06:53 <utkarsh2102> And secondly, limited hours. I can do much more in December and essentially help in reducing the queue if I have more hours. But probably that’s just me.
14:08:03 <buxy> If all the CVE are low severity, then I assume it's OK to split but at the same time people complain that we do too many updates so splitting is not good on that front. What about working at two or three on such a package collaborating in git?
14:08:50 <Beuc> For some old packages that cannot lead to immediate work (e.g. waiting undefinitely for upstream patch), they could be dropped; it would be FD's (non-duplicate) responsibility to check on them regularly.
14:09:48 <utkarsh2102> buxy: that would work for me for some packages, absolutely. I could just push fixes to git. For instance, that’s what I did with tiff. I pushed some fixes and then will do another round and then finally upload.
14:10:06 <pochu> o-
14:10:08 <pochu> o/
14:10:25 <helmut> collaborating on a single package feels like more overhead than benefit to me, but mutual review (both on patches and triaging) is something that may help with consistency
14:11:01 <buxy> apo suggested on the mailing list that we should assign old packages to contributors and they should then find some way to go forward, even if it means to figure out how to hire to write the patch... I quite like that idea. What do you think?
14:12:11 <utkarsh2102> buxy: you mean just assign packages directly and then they’ll take a look?
14:12:38 <bhe[m]> For me its the inertia of going for new packages than the ones I worked/known in past. I think collaborating might help.
14:14:19 <pochu> one way to reduce the number of packages would be to use no-dsa a bit more... unsure whether that's a desired outcome though
14:14:21 <buxy> utkarsh2102: yes, when a package has not been dealt in X weeks, then we decide it's time to try another approach than "pick what you want" and have someone take the responsibility to drive it forward, not necessarily fixing it alone, but finding some who can do it.
14:14:39 <tumbleweed> that sounds like the best way to clear those old things out, yes
14:16:04 <buxy> apo wanted to have a system to spread those forced assignation fairly, not sure who to achieve that
14:16:18 <utkarsh2102> that sounds reasonable to me.
14:16:28 <utkarsh2102> I’ll reply to the list as well.
14:16:29 <buxy> "who to" -> "how to"
14:16:32 <helmut> I find the no-dsa classification non-obvious at times and inconsistent at other times.
14:16:55 <apo> well, we are X contributors, just start with the letter A and move on to Z :)
14:17:04 <Beuc> I think it would be worth looking at concrete examples; which package are a problem (with sponsors and medium/critical CVEs to fix); Debian/stable itself has lots of unfixed CVEs that are sitting for long
14:17:31 <utkarsh2102> yes! 😭
14:17:42 <helmut> does find-work put the "problematic" packages to the top?
14:18:02 <buxy> BTW we really don't want no-dsa in LTS, either "postponed" or "ignored", but yes I agree that we should likely use that more often, it's also one of the reasons why I think getting secteam and LTS team closer could help to have consistent triaging
14:18:04 <utkarsh2102> this is a learning opportunity: fix things in stable, too. Because this is otherwise going to be repeated when bullseye becomes LTS.
14:18:35 <utkarsh2102> I’d re-highlight this again^
14:19:41 <buxy> helmut: it sorts by popularity among sponsors, it doesn't take into account age or anything like that
14:20:08 <tumbleweed> maybe we need to incorporate severity into that?
14:20:20 <helmut> when current-stable moves to lts, it'll have accumulated a big pile of no-dsa and if you look at any package, you'll find lots of the no-dsa issues in addition to the new ones and that may just have gotten us this backlog now?
14:20:38 <helmut> buxy: maybe hange the algorithm to also account for age?
14:20:40 <tumbleweed> helmut: yes, that's certainly part of the problem
14:20:54 <buxy> ack to both
14:20:56 <tumbleweed> the longer something goes without needing a real update, the more no-dsa issues it has accumulated
14:22:02 <helmut> I think we need to discuss more how to deal with stable in topic #4 to settle this
14:22:05 <buxy> #action gladk to file a bug requesting find-work improvement to include age and severity in the sorting algorithm
14:22:52 <pochu> stretch ELTS also has a big backlog, and that comes from LTS not from stable
14:23:33 <buxy> #agreed We should try apo's suggestion to "force-assign" old packages to contributors (in a fair way) and they should figure out ways to get the package fixed even if they are not doing it themselves, they must find people that will be able to
14:24:09 <buxy> Ok I think we spent enough time on this topic already. Let's continue.
14:24:18 <buxy> #topic Project Funding Changes
14:24:53 <buxy> So this mostly an information with an opportunity for you to give feedback.
14:26:34 <buxy> We stopped to use LTS money to grow the project funding pool a while ago. And with the introduction of Freexian collaborators that help Freexian to reach its goal of improving Debian, we believe it makes sense that the persons deciding on what to fund should be the set of collaborators and no longer the set of paid LTS collaborators (there's overlap obviously).
14:27:08 <buxy> "paid LTS contributors" sorry (not collaborators)
14:27:55 <buxy> We also received a new project funding request (submitted by tumbleweed):
14:28:03 <buxy> https://salsa.debian.org/freexian-team/project-funding/-/blob/master/proposed/2022-11-debian-reimbursements.md
14:28:29 <utkarsh2102> no immediate feedback but why this change?
14:29:15 <Beuc> Yeah it is a decision based on principle, or are we hoping to fix/improve something?
14:30:32 <buxy> utkarsh2102: because Freexian's mission statement is to improve Debian, and the people helping Freexian to reach its goals are the Freexian collaborators. Also since the money no longer comes from LTS but from Freexian's margin on other services (ELTS mainly), I find it more logical to restrict to collaborators.
14:31:34 <buxy> Beuc: nope, just wanted to give you an opportunity to react and make sure I conveyed the explanation properly
14:32:43 <buxy> Now regarding the above project, I'm still asking all the LTS contributors to approve it. I wanted to do it live today because I figure it's a no-brainer but if you disagree, let me know.
14:32:46 <utkarsh2102> buxy: okay, as long as LTS contributors are welcomed to give their suggestions and opinions, it's all good! :)
14:32:47 <pochu> buxy: it sounds reasonable
14:33:23 <helmut> I don't feel competent in judging the treasurer proposal. it's been a while since I've last reimbursed something, so it feels like really the treasurer team should have a say about this (dlange commented positively on the mr)
14:33:56 <buxy> I believe tumbleweed was in touch with them yes, he made the prototype for them
14:34:13 <buxy> tumbleweed: want to say a word before I open the informal vote?
14:34:32 <tumbleweed> yeah, they asked for this, and asked me because of work I've done in debconf. I applied for freexian project funding because I'm working with freexian, so it seemed reasonable
14:34:57 <tumbleweed> they were also willing to have debian pay for my time - they want it that badly
14:34:58 <helmut> what I kinda miss in the proposal is an expression of the pain that the involved teams experience with the rt based workflow
14:35:50 <tumbleweed> right, I'm outside of that pain. I can ask them to expand on that
14:36:32 <tumbleweed> I know that there is a definite lack of visibility into debian spending across TOs, because the information is spread across hundreds of emails
14:37:15 <buxy> here the infra would keep track of amounts and give an overview on spendings, right?
14:37:36 <tumbleweed> it would be able to, yes. Although any visualization of that is currently out of scope
14:38:30 <buxy> Do we know if other projects besides Debian have similar needs and/or could benefit from this?
14:38:38 <tumbleweed> SPI wants it too
14:38:49 <tumbleweed> we haven't asked elsewhere
14:39:26 <utkarsh2102> that seems enough to me already, hah. But more the merrier?
14:39:45 <buxy> Are we confident to vote based on what we know now, or shall we defer the vote to after we know more about the treasurer's pain points?
14:40:11 <utkarsh2102> I am ready. :)
14:40:33 <helmut> I trust dlange. +1
14:41:02 <buxy> Let's vote please, either +1 (approve) or -1 (reject) or +0 (abstain, neutral).
14:41:11 <utkarsh2102> +1
14:41:13 <bwh> +1
14:41:15 <pochu[m]> +1
14:41:18 <apo> +0
14:41:29 <Beuc> +1
14:41:38 <tumbleweed> +0 [ my request ]
14:41:41 <guilhem> +1 (fwiw, dunno if i'm eligible)
14:41:44 <bhe[m]> +1 I  think other projects already have this ( wikimedia, Gnome ?). So thumbs up from me to have this.
14:42:34 <buxy> Thanks. Closing the vote and the topic then.
14:42:46 <buxy> #topic Planet Debian and LTS reports.
14:43:19 <buxy> How can we continue to put our LTS reports on Planet Debian now that they moved to https://www.freexian.com/tags/debian-lts/ instead of my personal blog? I would like to add a "planet-debian" tag in the company blog and subscribe the associated RSS feed to Planet Debian. Is it OK? Do we need to ask permission? If yes, how and where?
14:44:33 <pochu[m]> I'm not too familiar with the policy but I think that should be fine
14:44:45 <helmut> buxy: sounds good to me. I suggest mailing planet@debian.org to inform them expecting them to agree and add it after say a week maybe?
14:44:49 <pochu[m]> Specially with a debian tag
14:44:50 <utkarsh2102> I don't see a problem?
14:44:58 <buxy> Clearly we mention to sponsors that our monthly reports show up on Planet Debian. I'm not sure if they care but I think it was certainly a simple way to give them some visibility.
14:45:10 <bhe[m]> Since its coming from a company handle. I think we need to ask.
14:45:30 <buxy> I looked at the policy recently, the closest I found was about a "Team blog":
14:45:37 <bhe[m]> where to ask ? I am not sure.
14:45:39 <utkarsh2102> I would say don't push the commit to master directly, open an MR against planet's website and let it be there for a while in case someone has any objections or whatever
14:45:49 <utkarsh2102> but that wouldn't gain a lot of traction anyway but still :)
14:45:59 <buxy> https://wiki.debian.org/PlanetDebian?action=show&redirect=DebianPlanet#Can_I_add_a_team_blog.3F
14:46:38 <buxy> Maybe the only change would be to tweak our feeds to include the "(by FooBar)" in the title.
14:46:52 <helmut> before having joined freexian, I valued the freexian posts more than a number of others. they're on-topic, sufficiently short, not too frequent. I'd value keeping them (personal opinion unrelated to freexian)
14:48:24 <buxy> #agreed the request seems reasonable, let's open MR and mail planet@debian.org to get some confirmation that it's OK. Tweak the feed to include the author of the post in the title.
14:50:00 <utkarsh2102> \o/
14:50:12 <buxy> I think I'll skip the secteam discussion and keep it for later, there's not much time left in the hour.
14:50:38 <buxy> #topic DD survey analysis
14:50:58 <buxy> Roberto said: no significant progress on my part since the last meeting, as my time has been consumed with Freexian internal tasks and ELTS work
14:51:35 <buxy> You have the link to the document in your mail archive somewhere, feel free to continue to provide comments. It has become a very large document that really needs an executive summary.
14:51:49 <buxy> That's among the remaining work for Roberto.
14:52:01 <buxy> #topic Meetings 2023. Schedule
14:52:36 <buxy> I'm not sure what's this entry. Who put it in the agenda? apo?
14:52:44 <apo> nope
14:53:09 <buxy> I assume it's a desire to fill https://lts-team.pages.debian.net/wiki/Meetings.html with the dates for next year
14:53:37 <buxy> #action gladk to update https://lts-team.pages.debian.net/wiki/Meetings.html with meeting dates for 2023
14:54:49 <buxy> BTW next month's meeting is on the 22nd, is it OK for most of you? it's before the 24th so it's probaly easier to have people compared to earlier years where it was between christmas and new year
14:54:49 <helmut> is there a public .ical file with the meetings?
14:56:00 <buxy> helmut: not that I know, but it's a rule-based entry (Monthly on the fourth Thursday)
14:56:50 <buxy> No one screaming so I assume that the 22nd is OK.
14:57:04 <buxy> A few positive confirmation would still be nice.
14:57:10 <bwh> OK for me
14:57:26 <bhe[m]> +1
14:57:37 <apo> that's fine
14:57:41 <guilhem> no pb
14:57:47 <helmut> the time is bad for me in general, but it's once a month, so meh
14:58:27 <buxy> Ok. Thank you everybody.
14:58:48 <buxy> #endmeeting