El 15/03/24 a las 08:31, Roberto C. Sánchez escribió: > On Fri, Mar 15, 2024 at 11:06:10AM +0100, Raphael Hertzog wrote: > > Hello Roberto, > > > > On Thu, 14 Mar 2024, Roberto C. Sánchez wrote: > > > Santiago and I are in agreement that at the moment the best available > > > option is to use dla-needed.txt even for tracking work that needs to > > > happen after the DLA is released, specifically working toward an upload > > > to (old)stable. > > > > Those processes can be quite long. So the entry in dla-needed might stay > > around with lots of historical comments and with someone assigned that is > > not actively doing anything on the package (waiting next > > stable update or similar). > > > > What happens then when a new CVE shows up for that package? > > > > It might not show up for triaging by frontdesk because the package is > > already listed... and the person assigned is not monitoring the list of > > CVE of the packages since they are basically waiting the next point > > release, or an answer from the security team, etc. > > > > Thus I have fears that this change might end up with us missing to be > > reactive on some updates. > > > This is a valid concern. > > > Some alternative proposals to try to be constructive: > > > > - add "foo/bullseye" or "foo/bookworm" entries to track separately the > > work on other releases (you need to check how the triaging script > > interact with that kind of entries) > > > > - use salsa issues to track those (what happened to the experiment to use > > salsa issues for regular updates BTW?) > > > At the moment, the documentation of the FD responsibilities and > procedures are a bit of a mess (mostly because I have not had sufficient > time to return to the work of revising the documentation). Sylvain has > very helpfully fixed some of the most glaring problems, but the > comprehensive revision is still needed. I am certainly in favor of using > Salsa for the longer-running "non-LTS" parts of the updates. > > I also prefer Salsa as a solution because as I began thinking about the > required tooling revisions to do everything in dla-needed.txt it became > apparent that the tooling could be somewhat complicated. Granted, the > approach of marking "foo/bullseye" or "foo/bookworm" for the entries > would avoid some of that complication. I will have to think about which > way the workflow would be more sensible for contributors and then > Santiago and I can discuss how to implement. While I see all the advantages of moving to Salsa issues, I value to have the most similar method and workflow than the security team for the LTS work. And that especially if we want to explicitly state when working on (old)stable is required (and someone has claimed a specific package). To be discussed :-) cheers, -- S
Attachment:
signature.asc
Description: PGP signature