Re: Expanding the scope (slightly) of dla-needed.txt
Hi, On Sat, 23 Mar 2024, Roberto C. Sánchez wrote: > In any event, I am happy to work towards reinitializing the Salsa issues > experiment to start again in April and then see how it goes from there. > > What do you think? It's a pity that nobody else responded... I'm no longer involved in day-to-day LTS work, but I believe this would be beneficial. Both in terms of efficiency of the workflow, and in terms of indirectly adding data that lets us analyze how we are performing (because tickets are easier to introspect to make statistics about how long we took to complete some update). > There are also opportunities for improvement that follow from this. For > instance, with proper use of tags, it would be possible to update the > security tracker code so that when you are looking at the status page > for a package, there is a section with links to Salsa issues from > lts-team/lts-update-tasks related to that packages. I assume this implies some per-package tags... I wonder if gitlab can reasonably cope with several hundreds of tags. I would be tempted to just rely on title parsing but that's details. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Re: Expanding the scope (slightly) of dla-needed.txt
On Thu, Mar 14, 2024 at 04:47:57PM -0400, Roberto C. Sánchez wrote: > Hello everyone, > > I have discussed with Santiago the idea of whether we need to somewhat > expand the scope of dla-needed.txt. > > In essence, we need to continue tracking packages as in-work in some > cases even after a DLA is released because we might be working with > secteam, (O)SRM, and/or the maintainer on an upload to (old)stable. > I think that in the past this has been handled somewhat informally > (e.g., someone prepared a DLA and then even after the package was done > from dla-needed.txt continued working on the (old)stable updates). > However, for the sake of transparency and clarity we should be keeping > track of this in some way. >... > - FD should be confirming that package removals from dla-needed.txt are > valid (i.e., that the package does not require any work towards an > upload to (old)stable) >... IMHO it would be a better approach if the coordinator would check this as part of the Weekly information, not different from other missing work like missing announcements or git tag. For every CVE fixed in LTS last week one of the following should be true: - package is not in stable, or - CVE is marked as fixed in stable, or - CVE is listed in data/next-point-update.txt, or - package is in data/dsa-needed.txt assigned or with an offer to help from the person who did the DLA, or - the CVE information in the security tracker gives a clear reason why no fix is required The last two checks would have to be done manually by the coordinator, but the first three could be automated. The same check can be done for oldstable, using data/next-oldstable-point-update.txt For fixes in ELTS, it could also be checked that a CVE is either fixed in LTS or the package in data/dla-needed.txt Salsa issues would then be opened for the rare cases of missing work, neither bloating dla-needed.txt nor duplicating information, and not different from a missing git tag. This would make the Weekly information even more the point (and deadline) where every contributor knows that some known checks will be run, which also has the positive effect that people will do the work in time. > Regards, > > -Roberto cu Adrian
Re: Expanding the scope (slightly) of dla-needed.txt
On Fri, Mar 15, 2024 at 06:48:58PM -0300, Santiago Ruano Rincón wrote: > > 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). > So, I spent some time looking at dla-needed.txt and dsa-needed.txt. While I agree completely that we want to retain similarity with the security team workflow where possible, I do not see a strong similarity between dla-needed.txt and dsa-needed.txt at this point. This is both in terms of content and in terms of change history/utilization. Of the 42 packages in dsa-needed.txt today, only 9 have a note attached. All 9 notes are a single sentence or sentence fragment. By contrast, fully 2/3 of the 55 packages in dla-needed.txt have substantive notes (i.e., a note other than "added by ..."). Many of the notes in dla-needed.txt span a half dozen sentences or sentence fragments. I do not have a great deal of insight into how the security team functions on a day to day basis, but I gather that they work differently in some key respects. Particularly, they seem less likely to pick up a package, set it down, transfer it between team members, etc. In that sense our workflow demands more thorough note keeping. I would argue that if we wanted to be more similar to the security team (in so far as the management of dla-needed.txt and trying to align it with dsa-needed.txt), then we should migrate to issues in Salsa. As I recall, the original idea that was proposed was that when a package is triaged in dla-needed.txt an issue would be created on Salsa (in the lts-team/lts-update-tasks project, and the creation could be automated). The entry in dla-needed.txt would consist of the name of the package, the person working on it at the time (if any), and a link to the issue in Salsa. This seems like it would bring several benefits: - dla-needed.txt would be far more compact and easier to consume for a human - less churn in the security tracker - a per-package place to discuss the various facets of the work (upstream coordination, testing, MRs, etc) There are also some drawbacks: - there are now two places with information about pending LTS work (dla-needed.txt and Salsa) - the tooling would need to be modified in order to provide an experience similar to the present experience - it would require some reworking of our processes Personally, I see the benefits as greater than the drawbacks and I think that at this point I have sufficient bandwidth to be able to help run a new experiment and then begin the transition process. One thing that we would need to discuss/decide is, assuming a workflow based on issues on Salsa, whether the single issue encompasses all the work (e.g., LTS update and any applicable update to oldstable/stable) or whether two issues are created (one for the LTS update and another for any applicable update to oldstable/stable). There are also opportunities for improvement that follow from this. For instance, with proper use of tags, it would be possible to update the security tracker code so that when you are looking at the status page for a package, there is a section with links to Salsa issues from lts-team/lts-update-tasks related to that packages. In any event, I am happy to work towards reinitializing the Salsa issues experiment to start again in April and then see how it goes from there. What do you think? Regards, -Roberto -- Roberto C. Sánchez
Re: Expanding the scope (slightly) of dla-needed.txt
Hi, On 17/03/2024 06:54, Sean Whitton wrote: On Thu 14 Mar 2024 at 04:47pm -04, Roberto C. Sánchez wrote: - it is important update the notes on packages in dla-needed.txt to indicate what work has been done and what remains I think that we should be also reviewing old notes and deleting those that don't matter anymore. I've been trying to do this with at least my own notes. My understanding is that the purpose of the document is more of a to-do list than a logbook. I believe they are both: initially pointing what needs to be done, then a log of what has been achieved so far (allowing coordinators and contributors to check on progress/issues). A bit like a Salsa issue :) Cheers! Sylvain
Re: Expanding the scope (slightly) of dla-needed.txt
Hello, On Thu 14 Mar 2024 at 04:47pm -04, Roberto C. Sánchez wrote: > - it is important update the notes on packages in dla-needed.txt to > indicate what work has been done and what remains I think that we should be also reviewing old notes and deleting those that don't matter anymore. I've been trying to do this with at least my own notes. My understanding is that the purpose of the document is more of a to-do list than a logbook. -- Sean Whitton signature.asc Description: PGP signature
Re: Expanding the scope (slightly) of dla-needed.txt
Hi, On 14/03/2024 21:47, Roberto C. Sánchez wrote: - FD should be confirming that package removals from dla-needed.txt are valid (i.e., that the package does not require any work towards an upload to (old)stable) Phrased that way, I don't really like the idea of FD checking on his peers' work. I believe this is better from a person with a hierarchical relationship (such as coordinator... :)), and long-term availability (by-week FD probably won't check Sunday's uploads, nor ping possibly busy contributors the next weeks to clarify if work is needed and/or underway). Technically the tracking should already happen in data/dsa-needed.txt (for a confirmed DSA) or bugs.debian.org tag=pu (for point updates). So we only want to track a temporary state when the possibility of a LTS-Team-made update is initially coordinated with secteam and/or package maintainer. Do we really need that? :) Cheers! Sylvain
Re: Expanding the scope (slightly) of dla-needed.txt
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 signature.asc Description: PGP signature
Re: Expanding the scope (slightly) of dla-needed.txt
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. Regards, -Roberto -- Roberto C. Sánchez
Re: Expanding the scope (slightly) of dla-needed.txt
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. 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?) Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Expanding the scope (slightly) of dla-needed.txt
Hello everyone, I have discussed with Santiago the idea of whether we need to somewhat expand the scope of dla-needed.txt. In essence, we need to continue tracking packages as in-work in some cases even after a DLA is released because we might be working with secteam, (O)SRM, and/or the maintainer on an upload to (old)stable. I think that in the past this has been handled somewhat informally (e.g., someone prepared a DLA and then even after the package was done from dla-needed.txt continued working on the (old)stable updates). However, for the sake of transparency and clarity we should be keeping track of this in some way. 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. What this means: - if a DLA is published, then the package should only be removed from dla-needed.txt if no other work (as described above) remains - if the preceding point applies, then it may be necessary to manually unstage the changes to dla-needed.txt that gen-DLA will stage automatically - once the other work is completed, then it may be necessary to manually remove the package's entry from dla-needed.txt - these last points clearly indicate that some updates to tooling may be needed - it is important update the notes on packages in dla-needed.txt to indicate what work has been done and what remains - FD should be confirming that package removals from dla-needed.txt are valid (i.e., that the package does not require any work towards an upload to (old)stable) Your help with this is very much appreciated. Regards, -Roberto -- Roberto C. Sánchez
