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