On Wed, 2025-05-28 at 21:49 +0200, Sylvain Beucler wrote: > > I wonder if the problem is a matter of package priority, rather than > no-dsa itself. [..] > I've got the feeling that many contributors pick updates in > xla-needed.txt without checking their priority in ./find-work. All the > planned work to fine-tune package priority using CVE severities won't be > useful if contributors never check the package priorities. While that may be true for some cases, it might only appear so for others. It is my impression that some packages are simply so complex or complicated that only a few people (if any) attempt to address them. An example that comes to mind is freeimage. I'm actually not aware of many other packages in dla-needed.txt that haven't been touched since 2024. IMHO the number is <=5. And a few like ceph are just in some kind of unknown state which might prevent them for being picked up. For ELA the situation seems different. But backporting patches to Buster, Stretch or even Jessie becomes a lot more complicated, and we naturally find more packages in need of an urgent upload without being worked on. But claiming that this is because LTS team members work too much on no-dsa is IMHO the wrong conclusion. I think it is a question of personal limits as well. Maybe we should consider teaming up on complex packages, so multiple people can work on the issues and prepare a DLA/ELA together if the package in question is a high-profile and long-standing one? Or allow to release DLA/ELA fixing only a subset of issues? For ELA maybe we should consider backporting versions from higher-up releases more often, so we have (ideal-case) only one version to maintain for Buster, Stretch, and Jessie instead of three. That would reduce the complexity and the workload. IMHO we will always find ourselves in the no-dsa vs. too-much-dsa space/debate. But my work on two no-dsa issues last month led to one DSA being released yesterday, and to the discovery that another CVE claimed to be fixed in Sid actually is still open. IMHO there is a lot of good coming from our current approach to address all open issues. Regards, Daniel
Attachment:
signature.asc
Description: This is a digitally signed message part