Le dimanche 6 avril 2025, 09:25:58 heure d’été d’Europe centrale Roberto C. Sánchez a écrit : > Hello everyone, > > I am in the early stages of putting together a sprint to take place at > DebCamp25, with the objective of making improvements to the security > tracker. With that in mind, I would like to ask a very specific > question: > > As you go about tasks which require interacting with the security > tracker, what pain points exist for you? > > Some background: > > Santiago and I have recently been discussing some improvements to the > security tracker with a specific focus on improvements to support our > workflow needs (both inward facing and outward facing needs, including > things that support the workflow of the LTS team and by extension the > Security team). As a result, we have a reasonably good idea of some > changes that we'd like to see implemented in order to support those > specific neds. > > As part of this effort I would also like to consider whether other > improvements are needed and/or desirable. The idea with considering > existing pain points and other improvements is two-fold. First is that > if we are going to undertake significant work on the tracker (vis-à-vis > a sprint) then this is also an opportunity to fix some other issues > along the way, thus improving the overall day-to-day experience for the > LTS team and the Security team. Second is that such improvements seem > likely to yield workflow improvements that I had not previously > considered. > > At the moment I am most interested in identifying the problem areas and > pain points rather than considering the potential solutions. That said, > while solutions aren't the focus of the question I am asking in this > mail, discussions of potential solutions to specific problems are fine. > I'd rather we not turn this into a discussion about hypothetical issues > nor a bikeshedding session on potential optimizations. > > As one example, some time ago I encountered the issue of the size of > data/CVE/list, specifically in the context of a git blame operation > taking a few hours to complete. I became convinced that data/CVE/list > needs to be split. As I've done some research on the topic, the answer > to that is far from clear. I'm less convinced now that "split > data/CVE/list" is the de facto right solution, and I'm definitely > convinced that a big change here will not be accepted without many good > reasons and proof that doesn't also include some massive drawbacks.
split per year will help here. And bonus point will help us LTS/ELTS wise to avoid conflict with more recent entry. > So, > in the context of this discussion I would consider "git blame takes an > unreasonably long time to be particularly useful" as a valid statement > of a pain point, and I would hesitate to favor a specific possible > solution. pain point: - PU should be taken in account for fixed version #645201 - Don't display unimportant issues as "vulnerable" #1039606 Otehr pain point: NOTE syntax should be improved or better documented for fixed version > > Regards, > > -Roberto
