Re: Revisiting some old DLAs
On Thu, Dec 12, 2024 at 12:59:46AM +0200, Adrian Bunk wrote:
> On Wed, Dec 11, 2024 at 02:35:00PM -0500, Roberto C. Sánchez wrote:
> > >
> > Only they aren't necessarily incomplete DLAs.
> >...
>
> I thought submitting DLA fixes also to (old)stable was part of our job.
>
Yes, it is part of our job. We want to help out in stable (both
-security and -proposed-updates), especially when we are already making
a fix in LTS.
> I have done -pu uploads for 14 of my DLAs and DSAs for 5 of my DLAs this
> year so far.
>
Which is outstanding. I mean that genuinely. This is exactly what we
envisioned as we began shifting from "help out with stable if you feel
so inclined and if the package version is the same" to "help out with
stable should be the default on every package update where it is
possible."
> > For some, the DLA was
> > already published and completed and what was "missing" was an assist to
> > the maintainer and/or SRM to get an update for a point release.
> >...
>
> I have a hard time understanding what you are thinking when you write
> "an assist to the maintainer and/or the SRM".
>
> DLA, DSA and (old)stable-pu all work similar:
> You upload a package and you send an email.
>
> The email might be a release announcement (DLA),
> or a debdiff for review (DSA, pu).
>
> And there are some differences in the order between upload and email.
>
> I don't recall if I ever fixed the same CVE in all 6 releases from an
> NMU in sid down to jessie, but if that happened it was 6 uploads with
> 4 different ways to announce/submit.
>
I apologize for not being clear.
We can look at our various tasks as follows:
- creation of a DLA (requires preparing the update, uploading the
package, and making the announcement)
- additional administrative work (recording the changes in git,
including w/ a signed tag)
- additional work in support of stable (-sec or -pu)
The first two are entirely within our authority as the LTS team and do
not require that we seek any external coordination. The last one,
however, does require external coordination. Sure, from a technical
process perspective it is very similar to what we do for a DLA (prepare
and upload a package, then send an email). However, those are things
that must be coordinated (in some way, before or after) w/ secteam or
SRM when it involves an upload to stable.
This distinction and the previous discussions about the scope of
dla-needed are why I elected to create issues for the stable updates,
rather than placing the packages back into dla-needed. Adding a package
back into dla-needed with a note like "no DLA actually needed since that
is done, what this is really here for is a stable update" seems less
appropriate than the issues in Salsa.
Now, this could all change if we collectively decide that we need to
substantially expand the scope of dla-needed or pivot to some other task
management solution entirely. But that is not something that we have
done yet.
Regards,
-Roberto
--
Roberto C. Sánchez
Reply to: