Hello everyone! Thanks to those of you who were able to participate and
I'm sorry that we missed those of you who couldn't make it.
Present in today's meeting: Sean, Chris, Adrian, Lee, Raphael, Santiago,
Thorsten, Roberto, Tobi, Sylvain, Guilhem, Stefano, Jochen, Utkarsh,
Helmut, Emilio
Absent: Bastien
========================================
Meeting notes and summary, by agenda item:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Fixes should go to unstable first?
NOTES/DISCUSSION:
It has been a longstanding LTS/ELTS policy we should make an effort to
coordinate with the Security Team and/or (O)SRM so that as we fix
issues in LTS (especially no-dsa issues) that also fix those issues in
current Debian releases. This ensures that users upgrading from LTS to
a newer Debian release do not end up with vulnerabilities which were
previously fixed on their systems being reopened.
There has been a suggestion recently that all fixes should go through
unstable first. The claimed benefit is that this reduces the chance of
a regression. In the discussion, it became clear that there is a
significant cost to this approach: substantial delays to LTS/ELTS
updates. Additionally, there are cases where it is not
possible/feasible to introduce the update into unstable first.
Tobi and Helmut pointed out that it is possible to do the work in
parallel in the sense of preparing the updates. Then the uploads to
LTS/ELTS can take place right away (as those are under the purview of
the LTS/ELTS team), while coordination for stable (with the Security
Team for issues that would warrant a DSA or RMs for no-dsa issues) and
unstable (with the package maintainer) can be done according to their
timelines and without blocking the LTS/ELTS updates. It was also
pointed out that these communications could be carried out via the
BTS, as when a CVE affects a package in unstable the Security Team
files a bug against that package. Alternate coordination with the
Security Team can also be carried out via email
(t...@security.debian.org), IRC (#debian-security), or the security
tracker (dsa-needed.txt).
Some concise guidelines:
+ Do not unnecessarily delay LTS/ELTS updates for the sake of
unstable/stable updates
+ Coordinate unstable/stable updates with maintainer/secteam/RM
+ Favor coordination/communication through the BTS when a bug exists
for the issue in question
+ If no bug exists, consider filing a severity 'important' bug
+ In the case of an unresponsive maintainer, we are able to NMU we
should adhere to the project-wide NMU policy in that case (i.e., use
appropriate DELAYED queue, send patch to bug, do not upload en
entirely new upstream release, etc.)
- Demo of what is provisionally called ftf ("functional test framework")
NOTES/DISCUSSION:
The project is currently published here: https://gitlab.com/lgarrett/ftf
Lee demonstrated provisioning of systems with a Samba file sharing
setup. Ansible roles are used for configuring multiple VMs (e.g.
buster and windows) and testing their interaction (e.g. for samba).
The whole thing is idempotent; so you can start with nothing
provisioned and it will provision as needed, or if machines are
already provisioned they will be used without need for additional
provisioning.
A question was raised about whether autopkgtest is capable of doing
the same thing. Lee mentioned several benefits over autopkgtest,
notably that network interactions between multiple hosts can be tested
with this framework and also that autopkgtest has limitations
regarding resource allocation (which would preclude an autopkgtest
spawning multiple VMs via kvm) and there are concerns about DMUP with
installation of Windows.
While the original problem which triggered the development of this
framework (the summer 2023 Windows 11 update which broke interaction
with Samba) is essentially obsolete at this point, there are other
potential use cases for this framework. Some examples include
functional testing of backported Samba packages, backport testing of
other "major" packages, and other complex test configurations (e.g.,
multi-master PostgreSQL).
- Review status of "old" packages, i.e.: packages needing an upload
since a long time ago
NOTES/DISCUSSION:
Santiago briefly mentioned some "old" packages that are still in work.
However, there is an open call for volunteers to tackle "old"
packages. We really need for contributors to help resolve the complex
issues that are keeping these packages in the queue for a long time.
Some work has already happened on rails, docker.io, and some others.
- Discussion about Available:Extra hours
NOTES/DISCUSSION:
Roberto brought up the Available:Extra account to make sure that
everyone is aware of its purpose. The goal is to enable people to work
on big or complicated packages that would exceed their usual
allocations.
- Any other business:
NOTES/DISCUSSION: Nobody had anything to bring up under AOB
========================================
Many thanks also to those of you who made notes in the pad during the
meeting.
And lastly, the next LTS meeting will take place on Thursday 2023-11-23
at 14:00 UTC, via IRC in the #debian-lts channel on OFTC. As always,
note your agenda items here: https://pad.riseup.net/p/lts-meeting-agenda
Regards,
-Roberto
--
Roberto C. Sánchez
