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
Reply to: