Dear Debian community,
This is bits from the DPL for July. You might like to consider it as my
personal report about DebConf25 since this is the only topic for these
bits (besides the very bottom paragraph about future conferences I will
attend).
FTPmaster BoFs at DebConf
=========================
At this year's DebCamp and DebConf, we had the opportunity to revisit
and build upon the important conversations we began at last year's
DebConf around the work of the FTPMaster team[f00]. Across four dedicated
sessions (brainstorming sprint in DebCamp with two sessions[f01], BoF
in DebConf[f02] as well as a followup BoF on the last day[f03] held by
Anton Gladky), we continued discussing how to improve the core processes.
Except for the first DebConf BoF[f02] all other events were profiting
a lot from the remote attendance of Jörg Jaspert. Thank you for your
support, Jörg.
I'd like to give some summary for the wider audience. The FTPMaster team
handles the following critical tasks:
1. Running the suites - responding to issues as they arise
2. Coordinating releases - in close collaboration with other core teams
3. Maintaining and developing tools - mainly in Python, PostgreSQL, and shell
4. Processing NEW, overrides, and removals - the team's primary day-to-day work
These responsibilities are essential to keeping Debian running smoothly,
and the current team continues to deliver impressively despite limited
capacity. I want to take a moment to express my deep appreciation for
their sustained and often under-recognized work.
Importantly, these BoFs were not just technical planning sessions - they
were also part of an ongoing effort to improve transparency and
communication between the FTPMaster team and the wider Debian community.
While there are long-standing topics that still need discussion, I'm
glad we now have a more open and constructive channel to do so. The
engagement we've seen in these sessions is a sign that things are moving
in a good direction, and I hope this spirit of dialogue continues.
In the following sections, I'll summarize some key ideas and outcomes
from these BoFs.
1. Documenting the release process
----------------------------------
One of the important topics raised during the FTPMaster BoFs at
DebConf25 was the need for better documentation of key procedures and
workflows - especially around major releases. As Jörg explained, minor
point releases are mostly automated by now, but full releases remain
complex. They involve not only the FTPMaster team, but also coordination
with several other core teams. Currently, there is no comprehensive
documentation of this process. What exists are logs - often tmux
sessions saved to disk - which can be helpful for re-use but are
difficult to interpret for anyone not already familiar with the details.
With the Trixie release approaching, we agreed that this is an excellent
opportunity to capture how the release process works in practice. Such
documentation could benefit not only the FTPMaster team, but also other
teams involved in the release, and help future contributors understand
the bigger picture.
A small group of developers and technical documentation writers have
kindly volunteered to support this effort. Their role will be to quietly
observe the release process and record what happens - without
interfering or slowing things down. The intention is not to scrutinize
or second-guess decisions, but simply to make the process more
transparent and better understood across the project.
2. Legacy Crypto Regulations and Their Impact on NEW Processing
---------------------------------------------------------------
The current process for accepting new packages into Debian is still
shaped by legacy export control regulations related to cryptographic
software.[f04] These rules require that all packages entering the NEW
queue remain there until they are personally reviewed by an FTPMaster -
on a specific host, using a limited set of tools - to ensure compliance.
At DebConf25, we revisited this topic with the goal of adapting our
processes to today's legal and technical realities. Jörg provided
invaluable input by summarizing the current situation and drafting
concrete legal questions to clarify with a lawyer. If it turns out that
the original constraints are no longer required, we may gain much-needed
flexibility in how NEW is processed.
For packages whose source code is publicly available - such as those in
main and contrib - the crypto-related concern appears largely resolved,
since we can usually verify what's included. The situation is less clear
for binary-only software in non-free, where we can't always determine
whether cryptographic functionality is present.
If the legal review confirms that the restrictions can be lifted or
adjusted, we'll be able to explore more efficient workflows: involving
more reviewers, enabling parallel work, improving transparency on review
status, and using better tools to assist the process.
3. High-Impact Tasks for Contributors Outside the FTPMaster Team
----------------------------------------------------------------
During the BoFs at DebConf25, we identified several areas where
experienced developers - even those not part of the FTPMaster team - can
make meaningful contributions. These tasks don't require special
FTPMaster privileges, but they do require a solid understanding of
Debian infrastructure. If you're looking for high-impact ways to improve
core processes, these are excellent opportunities to get involved.
I was especially encouraged that, after last year's BoF, one developer
was inspired to open a merge request enhancing DAK[f05]. It would be
wonderful to see similar initiatives for the following areas:
A. Smarter Handling of Binary Package Name Changes
Bug #879779 requests automatic acceptance of certain classes of new
binary packages, such as renamed binaries. This would help avoid
unnecessary NEW reviews and reduce bottlenecks. Jörg raised the same
idea again in a four year old mail to debian-devel[f06].
B. Building Binary Artifacts for Review
While Debian maintainers typically perform source-only uploads,
FTPMasters need to inspect the actual binary artifacts during NEW
processing. Creating a reliable way to build these binaries - ideally
reproducing exactly what would be uploaded - would significantly
streamline the review process. This could be a build tool, a CI job,
or integration into existing infrastructure.
C. Migrating API Documentation from Epydoc to Sphinx
The current FTPMaster tooling is documented using Epydoc, which is
removed from the archive (it was last available in Debian Buster).
Migrating the documentation to Sphinx would improve maintainability
and make it easier for others to contribute and navigate the codebase.
D. Migrating to New Version of SQLAlchemy
The FTPMaster codebase uses SQLAlchemy, and the 2.x release
introduced significant API changes that require adaptation of
existing code. Updating to the new version is necessary to stay
compatible with current and future Python environments. Help with this
transition would be very welcome - particularly from contributors
familiar with SQLAlchemy's ORM and the changes introduced in 2.x.
E. Adding Python Type Annotations
Improving the internal type safety of the FTPMaster code by adding
PEP 484-style type annotations is another area where contributions are
encouraged. This helps improve code clarity, tooling support, and
long-term maintainability.
These are not beginner tasks, but they are important ones. Contributions
here could have a wide-reaching effect on Debian's ability to scale
package processing and improve our overall release pipeline. If you're
interested in tackling one of these, please reach out - thoughtful
collaboration is always welcome.
[f00] https://debconf24.debconf.org/talks/154-meet-the-ftpteam/
[f01] https://debconf25.debconf.org/schedule/reforming-ftpmaster-team-sprint/
[f02] https://debconf25.debconf.org/talks/3-package-acceptance-in-debian-challenges-and-opportunities/
Pad: https://pad.dc25.debconf.org/p/3-package-acceptance-in-debian-challenges-and-o
[f03] https://debconf25.debconf.org/talks/235-followup-reforming-ftpmaster-team/
[f04] https://www.debian.org/legal/cryptoinmain
[f05] https://salsa.debian.org/ftp-team/dak/-/merge_requests/286
[f06] https://lists.debian.org/debian-devel/2021/07/msg00231.html
Dormant packages BoF at DebConf
===============================
During DebCamp, I invited the developer community to join a sprint[d01]
to gather input on how we handle dormant or outdated packages. The ideas
collected there were later discussed in a dedicated BoF[d02], which was
inspired in part by the Bug of the Day[d03] initiative. That project has
shown that, while we often identify outdated or problematic packages,
there are currently no efficient procedures in place to modernize them
at scale.
As a starting point, we revisited a proposal I had shared on
debian-devel in December last year[d04]: allowing any Debian Developer
to upload packages, with the option for maintainers to opt out. The
suggestion is primarily aimed at obviously dormant packages - not
critical ones like the Linux kernel or standard libraries, where
developers are expected to act with the same caution and respect they
already show today. We trust Debian Developers not to blindly upload
sensitive packages, and of course, any such upload would carry the same
responsibilities and expectations as a Non-Maintainer Uploads. The
pad[d01] from the sprint contains a number of suggestions and proposals
related to this idea.
One point raised during the BoF was the need to better document the role
of the Debian/ group on Salsa. Not all developers are aware that being
part of this group allows any DD to upload packages hosted there. While
this is already documented in the Wiki about Salsa[d05], it might be
worth mentioning in the Developers Reference to make it more
discoverable (patches welcome).
We also touched on related processes like package salvaging[d06], and
the idea of a similar mechanism that would lead to orphaning a package
rather than adopting it. However, as these processes may become less
relevant if we revise our general upload policy, this part of the
discussion received less attention.
[d01] https://debconf25.debconf.org/schedule/preparation-of-dealing-with-dormant-sprint/
Pad: https://pad.dc25.debconf.org/p/2-dealing-with-dormant-packages-ensuring-debian
[d02] https://debconf25.debconf.org/talks/2-dealing-with-dormant-packages-ensuring-debians-high-standards/
[d03] https://salsa.debian.org/qa/tiny_qa_tools/-/wikis/Tiny-QA-tasks#bug-of-the-day
[d04] https://lists.debian.org/debian-devel/2024/12/msg00101.html
[d05] https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
[d06] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html\#package-salvaging
Bits from the DPL
=================
I don't intend to repeat the contents of my Bits from the DPL talk[b01]
here, but I do want to share a small addendum. During the talk, I
highlighted patience as one of the most important qualities of a Debian
Developer - and here's a real-world example to go with that.
In the upcoming Trixie release, bug #186085 - which I filed over 22
years ago - will finally be fixed. I'm genuinely thrilled to see this
happen while I'm serving as DPL, even though I contributed almost
nothing to the actual fix. In fact, I probably could have sat down and
done the work myself years ago. So if you're ever tempted to say, "That
took forever!" - remember: sometimes you could be the person who makes
it happen sooner. ;-)
I'd like to take this opportunity to thank Holger Wansing and the entire
Debian Installer team - not only for resolving this long-standing issue,
but for their continued dedication to an essential part of Debian.
Seeing this bug finally fixed after so many years has been genuinely
uplifting, and it's one of those moments that reminds me how much can
happen when persistence and community effort come together.
[b01] https://debconf25.debconf.org/talks/4-bits-from-the-dpl/
My personal reflections on DebConf25
====================================
As always, I was amazed to reconnect with so many friends. Even at
DebCamp, I kept running into people I hadn't seen in a year - or even
longer. Looking back, I realize there were still many more I had hoped
to talk to, but sadly didn't manage. Hopefully, I'll catch up with them
at a future, more relaxed DebConf - one where I might be "less
interesting" again as a regular developer (though I've learned it's
apparently not that easy to shake off the DPL hat - something I would
have loved to do, as I feel much more at ease speaking with people as
just another Debian contributor).
One highlight for me was seeing that my trip to FOSSASIA in Bangkok
earlier this year really paid off. I was delighted to welcome Krista to
DebConf25 - and proud that the effort to build a bridge with the vibrant
Asian Free Software community is bearing fruit. I hope we can continue
expanding this outreach and attract even more contributors from the
region. While some countries in Asia are already well represented in
Debian, there are still many "white spots" on the map - as you may have
seen in my Bits from the DPL talk - where we have no developers at all
yet.
As in past years, I thoroughly enjoyed the social events - the Cheese &
Wine party, the daytrip, and the conference dinner. Being in France, the
cheese and wine were exceptional. We also had an impressive selection of
desserts, including some very nice pastries sourced by the local
organizers. Thanks to the volunteers who kept everything running
smoothly and made sure none of the food went to waste!
My choice for the daytrip - Ushant island - couldn't have been better. I
love the rugged coastline of Brittany, and swimming at the westernmost
beach of mainland France was a special treat. I haven't had time to sort
through my photos yet, but I'll share them soon.
The conference dinner was another memorable moment. I wish I could have
tried everything on offer, but I was too busy enjoying great
conversations. The location and lighting at sunset were just right - and
inspired some of my Indian friends to re-create a well-known advertising
video from India, only this time promoting something far better:
Debian![r01]
I keep a personal distinction between swimming and non-swimming DebConfs
- and DebConf25 was definitely a swimming DebConf. I made it into the
water every morning at sunrise, and again before dinner. I enjoyed it
immensely.
This DebConf wouldn't have been possible without the generous support of
our sponsors, and I want to thank them explicitly. Even more thanks go
to the tireless organizers and every single volunteer who made DebConf25
such a success.
[r01] https://aana.site/@subins2000/114889983587945837
Other conferences
=================
I've just registered for two upcoming events:
1. Open Source Summit Europe - Amsterdam (24-28 August)
I'll be attending in my employer's capacity and just as a regular
participant - but I'd still love to meet up with anyone from the Debian
community living in or near Amsterdam.
2. Kieler Open Source und Linux Tage (18-20 September)
I'll be giving a talk, have a packaging workshop and supporting Ilu at
the Debian booth. We'll likely need a few more helping hands - so if
you're nearby and would like to help out, please get in touch!
I'm looking forward to meeting some of you at one (or both) of these events!
[c01] https://events.linuxfoundation.org/open-source-summit-europe/
[c02] https://www.kielux.de/
Kind regards
Andreas.
Attachment:
signature.asc
Description: PGP signature