• Bits from the DPL

    From [email protected]@21:1/5 to All on Tue Aug 31 13:20:02 2021
    Dear Debian Developers

    We continue to face extraordinary times together. The current pandemic has likely touched each one of us in some form or another, and yet, it's inescapable that it's but one of the many crises we share together on this piece of rock traveling through
    space.

    I'm incredibly proud of what the Debian community manages to achieve even as we face adversity both as individuals, and as a project.

    Earlier this month, Debian 11 (bullseye) was released[1]. This release happened a bit later than we would've liked, but fortunately it resulted in an exceptionally high quality release and feedback so far have been great. The release team originally
    considered a much earlier release date, but there's been some complications along the way. Having followed them closely over the last few months, I'm very thankful of the really great work that they've been doing, so a sincere thanks to the release team
    for all their efforts. Also to everyone else who have contributed the the bullseye release, that is a very long list of individuals!

    Over the last week, we've had our 22nd DebConf event[2]. Like last year, this was also an on-line event. It certainly had a more somber aura than last year's event, many of us had hoped last year that by now we'd be able to get back together and meet in
    person again. Despite some COVID-era fatigue, it turned out to be a good event, we had a number of high quality talks, were still able to put some faces to names and
    still managed to have some fun too. Thanks to everyone who attended or contributed to DebConf21 in some form or another!

    - From my side, I did submit a "Bits from the DPL" talk for the conference, but a torrent of continued incoming stuff got in the way of recording the talk. I prepared most of it already, so I thought I'd go ahead and be traditional and do this in a few e-
    mails instead and do the traditional Bits from the DPL talk in a later conference during this term.

    == Finances ==

    As a recap, here are the numbers taken from the DC20 Bits from the DPL talk:

    === 2020 ===

    Debian France: €43 543 (US$51 055)

    Debian.ch: CHF 83 323 (US$90 754)

    SPI:

    DebConf earmarks: US$127 422

    Debian main: US$626 834

    - --------------------------------------------------------------
    Total: $896 065


    And here are the updated figures:


    === 2021 ===

    Debian France: ~ €68953 (USD $80 764)

    Debian.ch: CHF ~107 868 (USD $117 926)

    SPI:

    DebConf earmarks: US$31 156

    Debian main: US$750 268

    - --------------------------------------------------------------
    Total: ~ $980 204


    I mark the numbers as approximate because there are some AGMs that still need to happen in order to finalize numbers, but the total is a very close approximation of our current available funds.

    To the casual observer, it may appear that our total balance is simply ballooning. Fortunately, this is not the case. We ended up doing a great job at spending money to improve Debian. This included some significant DSA upgrades (some I believe still in
    progress, I should probably poke them to do a bits from DSA post!), a bunch of laptops (among them, our installer team finally has some new nvidia/ryzen hardware to test with), and various other bits of components for DDs that include a Sparc CPU, memory,
    hard disks and other such miscellaneous expenses.

    As DPL, I was able to approve every request that was made over the last year. This was made easy thanks to the generous donations that both individuals and corporations make to the project. So thank you to all the donors who help our volunteers to save
    time and make their work on Debian either easier or even possible all together.

    For me as DPL, it's a very sore point that we can benefit so much from in-person meetings such as sprints or even user meet-ups, and that we have the cash to fund all incoming requests and yet the current circumstances simply doesn't allow that.

    I was glad to see another BoF for Local Groups at this DebConf[3], I think it will be important that when we start putting together some form of new normal, that we foster and develop our local groups because this is one of the best ways to increase our
    reach and gain more contributors and increase our diversity.

    During the remainder of my term, along with other Debian Developers on the debian-project mailing list, I aim to put together a set of policies that may help make it easier for DDs to request funding and also for local groups to pay for things like
    stickers, pens, pizza, beer, cake, tea, etc. During the last year and a bit I've often had to encourage people to send through a re-imbursement request, or have had to spend some time explaining to them that it really is ok for Debian contributors to
    spend Debian money to make Debian better. More benefits of having a spending policy codified is that approvals would be more consistent depending on who's DPL, we'll have some base that we can modify going forward based on our experience, and perhaps we
    can delegate some (or all) approvals to the treasurer team if they tick a certain selection of boxes. During the last two DPL election periods, the discussion came up again on whether we should have some form of DPL committee, or a project board. I think
    that at the very least, it would be good to reduce bus factor on the DPL role, and a good way to do that is to keep delegating more of the responsibilities. Having more policies and guidelines in place makes this possible.

    == General Resolutions ==

    Over the last few years we've had some tough GRs to deal with. I'm hoping that we can work together and show some compassion to one another for the upcoming GRs. None are in progress yet, but now that both the bullseye release and DebConf21 is over, I
    suspect that we'll be returning to our usual scheduled discussions, and it seems that at least a few of those that were in progress over the last year might result in GRs.

    So I urge you once again to practice some understanding. So much bitterness has risen in the past from people not understanding each other. There's tremendous value in making sure that the person on the other side actually meant what you thought they
    meant. In many cases when I've done this (especially when surprised at what they said), it turned out that they had simply left out something as simple as a "not" in a sentence. So, please don't make anger and frustration your default, there are other
    and better ways to deal with disagreements. When you fundamentally disagree with something, please make your voice heard. But please, if you've done that, you don't have to reply to every single mail in a thread to re-state that view ad nauseam.

    == Legal ==

    You might have noticed in our public financial reports via SPI that we've been spending more money on legal fees. Myself and a small team have been working on a very unpleasant problem for a while now, and after many many hurdles, we seem to be getting
    close to a point where we can make a public statement about this, probably within the next 2-4 weeks.

    == Other ==

    I have a whole bunch of important topics that I'd like to bring up, which I'll do on the debian-project list instead. If you don't follow there (which I believe you should if you're a project member), then I'll provide some summaries in the next Bits
    from the DPL.

    If you've made it this far, thanks and stay safe!

    - -Jonathan, Debian Project Leader

    == Links ==

    [1] https://www.debian.org/News/2021/20210814
    [2] https://debconf21.debconf.org/
    [3] https://debconf21.debconf.org/talks/38-local-groups-bof/

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEExyA8CpIGcL+U8AuxsB0acqyNyaEFAmEs81kACgkQsB0acqyN yaE+0A/6A2ip9f60QyrMsKtuYokSYfWs/VMro+p/kgk86a/xSGbtCUz212RvzXqG BkHxzYHT0RwsTaI+bPDwnq1MqPpzTrNfZq2uYbDLAoHqpapyHNdCKvQY9NnK+me9 sIg4CxN5l/FZsR6G6g0A7/n6bynyTSJpFWz34Kzj3XN6AGseGrXukcqBbKJf3Mx8 M4xLXY6egcItKH7di5qsQKLa5Qx1biT4Mz5qBvYtnuaeW7bvFI/ETj/+8ezQ1iMo me5bR6Y3OTExy09/ZgJ43NkQbm/SgbIHST0/QfVbxQjVDGvfZuweCxXaYbfTBaGv YcaoB/Zw82UtLgU0LXrqwKyi3dOYCgNWe3QAmqeEousGkEKmt1W/pHUK081jjVKs +J/y1NEgjvMlbYra/QaOOHYAKnMFmQzbwn6HCCH9IhC3xSeCUFVy9O4D4qt7q56o KO77THhbOF6I9v1eclv6YEAWJe4S3I2I4pn7/FOYOnk684Bh5aO3CbuI3y/gh0Bz QMa1aHTpVMy4L6NLzqqD6aHsw0V5HEcAaaRm1gJ99pERd/4gTUUzegdz8In7YZrQ 77hzoo29XhB7AnvFXokyk91kjyxtmamtY7vQql1aEsqgFdQaorFu68p3OcM1UC9m 7+SOkCVHjX31SqwRGSAHyJgu7YIsddjQkWIhzjR523jm/b+X7XI=
    =jDR0
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to All on Wed Apr 20 08:30:01 2022
    Hello Debianites

    Herewith follows some bits from the DPL.

    In this edition:

    1. Decisions
    1.1. GR: Change the resolution process
    1.2. GR: Voting secrecy
    1.3. Public statements on world events
    1.4. DPL Election
    1.5. Community structure and processes

    2. Bookworm preliminary freeze dates available

    3. News from sponsors / partners
    3.1. Freexian survey
    3.2. Microsoft sponsoring LWN for DDs

    4. Meetings
    4.1. DPL/DAM/CT Sprint
    4.2. Debian Montr�al meetups
    4.3. Debian Reunion
    4.4. DebCamp and DebConf

    5. Debian Publicity


    == 1. Decisions ==

    We've been quite busy making decisions, and it doesn't seem like we're slowing down on that front any time soon.

    1.1. GR: Change the resolution process

    During previous votes, several problems have been discovered with the constitutional mechanisms used to prepare either a vote for the TC or for a GR. This resolution addresses these issues along with another issue where the role of the TC chair wasn't clearly defined in the event of a tie.

    https://www.debian.org/vote/2021/vote_003

    1.2. GR: Voting secrecy

    Several developers have expressed that our public voting system had an effect on their vote. Sometimes this could affect whether they voted at all or have simply made them feel uneasy at times.

    This GR passed the resolution of making all votes private, similar to the DPL elections.

    https://www.debian.org/vote/2022/vote_001

    1.3. Public statements on world events

    A GR proposal was made to provide a statement on the war in Ukraine, and while it didn't result in a vote, it does seem to remain an unanswered question of how we want to deal with situations like these in the future. I hope that we can follow up on that point another time, since I do believe there are ways in which we can be more socially responsible as a project.

    https://lists.debian.org/debian-vote/2022/03/msg00259.html

    1.4. DPL Election

    The DPL election for the 2022 term has concluded. I'm happy to be serving a 3rd term as DPL, thank you all for your trust and support!

    https://www.debian.org/vote/2022/vote_002

    1.5. Community structure

    Over the years, the Debian Account Managers (DAM) have had to take on an increasing amount of responsibility within the project, mostly because there were no other structure put in place to take on those responsibilities. In recent years, the Debian Community Team (CT) has helped alleviate some of this, but it's been clear from feedback from DAM, CT and the general Debian community that we need some reform so that responsibilities are better distributed, and that we have teams that can serve the project's needs without burning out individuals within those teams.

    Russ Allbery pondered whether a better moderation structure / team might help alleviate some of the problems:

    https://lists.debian.org/debian-project/2022/02/msg00062.html

    Discussion on this is mostly stalled at this point, there's been a lot going on recently, and hopefully we can continue this soon and find some concrete ideas.


    == 2. Bookworm preliminary freeze dates available ==

    The release team have announced preliminary freeze dates for the Debian 12 (bookworm) release.

    2022-01-12 - Milestone 1 - Transition and toolchain freeze 2022-02-12 - Milestone 2 - Soft Freeze 2022-03-12 - Milestone 3 - Hard Freeze - for key packages and packages without autopkgtests To be announced - Milestone 4 - Full Freeze

    The freeze is meant to be short, so please plan accordingly with these dates in mind.

    https://lists.debian.org/debian-devel-announce/2022/03/msg00006.html


    == 3. News from sponsors / partners ==

    3.1. Freexian survey

    Freexian has been looking at various ways to fund Debian Developers and the work that their work on Debian projects. The Debian Developers behind Freexian have put together a survey about usage of money in Debian.

    You need to be a Debian Developer in order to participate, the survey closes on 23rd of April. More details about this survey, and a direct link to the survey is available below:

    https://lists.debian.org/debian-devel-announce/2022/04/msg00002.html https://surveys.debian.net/index.php?r=survey/index&sid=347114&lang=en

    3.2. Microsoft sponsoring LWN for DDs

    Linux Weekly News is a great source of news on what's happening in the free software world, and having it available for free to our members is a valuable resource. Currently 520 accounts are associated with Debian, and the Linux Systems Group at Microsoft has picked up the bill for this again this year. If you're a Debian Developer who wishes to activate their subscription, please visit the MemberBenefits wiki page.

    https://lwn.net/ https://wiki.debian.org/MemberBenefits


    == 4. Meetings ==

    4.1. DPL, DAM, CT Sprint

    In January, the DPL, DAM and CT had a sprint to discuss a bunch of outstanding topics. This occurred over a few video calls, since the pandemic got in the way of having an in-person sprint.

    Sprint report:

    https://lists.debian.org/debian-project/2022/02/msg00017.html

    4.2. Debian Montr�al

    The Debian Qu�bec local group are planning to have in-person meetings in Montr�al again. For details, sign up to their mailing list, linked on their wiki page:

    https://wiki.debian.org/LocalGroups/DebianQuebec

    4.3. Debian Reunion

    2020 was set to be our biggest year of MiniDebConf events to date. Unfortunately the pandemic has put quite a harsh dampener on that. Fortunately, things are kicking off again and Debian Reunion will be a MiniDebConf style event with a few days of working together followed by two days of talks.

    The event is taking place the last week of May in Hamburg, Germany. Talks will be streamed, so add the event to your calendar even if you can't make it in person!

    https://wiki.debian.org/DebianEvents/de/2022/DebianReunionHamburg

    4.4. DebCamp and DebConf

    DebConf is set to be an in-person event again this year. DebCamp takes place from 2022-07-10 to 2022-07-16, followed by DebConf which will take place from 2022-07-17 to 2022-07-24 in Prizren, Kosovo. Bursaries are available for people who require funding to attend, and the Call for Proposals for talks and events are open. Follow the links below for further details.

    Thank you to our platinum sponsors Lenovo, Infomaniak, Innovation & Training Park Prizren and Google.

    https://debconf22.debconf.org/ https://debconf22.debconf.org/about/bursaries/ https://debconf22.debconf.org/cfp/


    == 5. Debian Publicity ==

    Some of these items are probably better suited for Bits from Debian than Bits from the DPL, so if you ever have some free time, please consider writing a bit for them (it's just some markdown in git), they can help you get started on #debian-publicity (just be patient if you ask a question, they aren't awake 24h a day!). If you're working on something interesting and don't have time to write about it, also let them know, perhaps it would be fun for someone else to write about it.

    https://bits.debian.org/

    Thanks for reading! Keep well and happy hacking!

    -Jonathan


    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEExyA8CpIGcL+U8AuxsB0acqyNyaEFAmJfp2QACgkQsB0acqyN yaHcZQ/9GE+MfcMuXzPJ7fmtS1TYd0Zvjtrubmaaz9N1xstOKx6aJ+Lm5iuy963p s6z/0zKKLfME5m1MG5JF8/wtISg2LLD8hAILSf0e+xpONfC/TWjGWmwP8og8Jjdl 26dkYjLXaRjRYaAqDc8JuznlTNVQRXu5x/RLNAyVi0/tYCZrUKIBi9saYSjmPr2U HfmqbKaFFXQhMTbAcGUU6jYyx1i94EdcwgNtUSrxOTLKgo5w1mxogwsD7V054UOH JlKIreiFl2//IMW46nXTbFXcb3uhEnl4Z3MKKm1gT/N1ldjV4won7gdaeMdrWl9v EJc5YA0eukBDSt17XiFu4bsOGHU6HheIx9SZeh+QEdoDu2uU/XxVR71dXf/Pp2lN 58QjJMjB+LRMULlYMBfDU2RzHJJcVzcPJ8VoQwf3FWmQcUT7viuAzl3/bKuJvIFz tqJY9t1+T8WMXntTsIUz6iggmrbQ78oF+O5EA1+Dbkjmew/4EwWzGq7JWpGOYI5E vbIG4B72J6LODV6Jux5ZkdY9Wk94DuQ5Rkk6wS6KpsKa0unYl6PEJKfJYEGZPTuW di5rDgfLcDgv2tEAmaI1U2XAsTdkpySSM11LrrT113bJ6GOIuoHdzbaOPe0ocucJ OCFuOdUrXG/3xqTLCLr5xwTpeZE+ccyEyVLnpXcJ8wSgeFhLSNg=
    =ikaV
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Carter@21:1/5 to All on Sat Apr 6 09:51:14 2024
    Dear Debianites

    This morning I decided to just start writing Bits from DPL and send
    whatever I have by 18:00 local time. Here it is, barely proof read,
    along with all it's warts and grammar mistakes! It's slightly long and
    doesn't contain any critical information, so if you're not in the mood,
    don't feel compelled to read it!

    == Get ready for a new DPL! ==

    Soon, the voting period will start to elect our next DPL, and my time
    as DPL will come to an end. Reading the questions posted to the new
    candidates on [debian-vote], it takes quite a bit of restraint to not
    answer all of them myself, I think I can see how that aspect contributed
    to me being reeled in to running for DPL! In total I've done so 5 times
    (the first time I ran, Sam was elected!).

    Good luck to both [Andreas] and [Sruthi], our current DPL candidates!
    I've already started working on preparing handover, and there's
    multiple request from teams that have came in recently that will have
    to wait for the new term, so I hope they're both ready to hit the
    ground running!

    [debian-vote] Mailing list: https://lists.debian.org/debian-vote/2024/03/threads.html
    Platform: https://www.debian.org/vote/2024/platforms/tille [Anrea]
    Platform: https://www.debian.org/vote/2024/platforms/srud [Sruthi]

    == Things that I wish could have gone better ==

    - Communication:

    Recently, I saw a t-shirt that read:

    Adulthood is saying, 'But after this week things will
    slow down a bit' over and over until you die.

    I can relate! With every task, crisis or deadline that appears, I think
    that once this is over, I'll have some more breathing space to get back
    to non-urgent, but important tasks. "Bits from the DPL" was something I
    really wanted to get right this last term, and clearly failed
    spectacularly. I have two long Bits from the DPL drafts that I never
    finished, I tend to have prioritised problems of the day over
    communication. With all the hindsight I have, I'm not sure which is
    better to prioritise, I do rate communication and transparency very
    highly and this is really the top thing that I wish I could've done
    better over the last four years.

    On that note, thanks to people who provided me with some kind words
    when I've mentioned this to them before. They pointed out that there
    are many other ways to communicate and be in touch with the community,
    and they mentioned that they thought that I did a good job with that.

    Since I'm still on communication, I think we can all learn to be more
    effective at it, since it's really so important for the project. Every
    time I publicly spoke about us spending more money, we got more
    donations. People out there really like to see how we invest funds in
    to Debian, instead of just making it heap up. DSA just spent a nice
    chunk on money on hardware, but we don't have very good visibility on
    it. It's one thing having it on a public line item in SPI's reporting,
    but it would be much more exciting if DSA could provide a write-up on
    all the cool hardware they're buying and what impact it would have on developers, and post it somewhere prominent like debian-devel-announce,
    Planet Debian or Bits from Debian (from the publicity team).

    I don't want to single out DSA there, it's difficult and affects many
    other teams. The Salsa CI team also spent a lot of resources (time and
    money wise) to extend testing on AMD GPUs and other AMD hardware. It's fantastic and interesting work, and really more people within the
    project and in the outside world should know about it!

    I'm not going to push my agendas to the next DPL, but I hope that they
    continue to encourage people to write about their work, and hopefully
    at some point we'll build enough excitement in doing so that it becomes
    a more normal part of our daily work.

    - Founding Debian as a standalone entity:

    This was my number one goal for the project this last term, which was a
    carried over item from my previous terms.

    I'm tempted to write everything out here, including the problem
    statement and our current predicaments, what kind of ground work needs
    to happen, likely constitutional changes that need to happen, and the
    nature of the GR that would be needed to make such a thing happen, but
    if I start with that, I might not finish this mail.

    In short, I 100% believe that this is still a very high ranking issue
    for Debian, and perhaps after my term I'd be in a better position to
    spend more time on this (hmm, is this an instance of "The grass is
    always better on the other side", or "Next week will go better until I
    die?"). Anyway, I'm willing to work with any future DPL on this, and
    perhaps it can in itself be a delegation tasked to properly explore
    all the options, and write up a report for the project that can lead to
    a GR.

    Overall, I'd rather have us take another few years and do this
    properly, rather than rush into something that is again difficult to
    change afterwards. So while I very much wish this could've been
    achieved in the last term, I can't say that I have any regrets here
    either.

    == My terms in a nutshell ==

    - COVID-19 and Debian 11 era:

    My first term in 2020 started just as the COVID-19 pandemic became
    known to spread globally. It was a tough year for everyone, and Debian
    wasn't immune against its effects either. Many of our contributors got
    sick, some have lost loved ones (my father passed away in March 2020
    just after I became DPL), some have lost their jobs (or other earners
    in their household have) and the effects of social distancing took a
    mental and even physical health toll on many. In Debian, we tend to do
    really well when we get together in person to solve problems, and when DebConf20 got cancelled in person, we understood that that was
    necessary, but it was still more bad news in a year we had too much of
    it already.

    I can't remember if there was ever any kind of formal choice or
    discussion about this at any time, but the DebConf video team just kind
    of organically and spontaneously became the orga team for an online
    DebConf, and that lead to our first ever completely online DebConf. This
    was great on so many levels. We got to see each other's faces again,
    even though it was on screen. We had some teams talk to each other face
    to face for the first time in years, even though it was just on a Jitsi
    call. It had a lasting cultural change in Debian, some teams still have
    video meetings now, where they didn't do that before, and I think it's a
    good supplement to our other methods of communication.

    We also had a few online Mini-DebConfs that was fun, but DebConf21 was
    also online, and by then we all developed an online conference fatigue,
    and while it was another good online event overall, it did start to
    feel a bit like a zombieconf and after that, we had some really nice
    events from the Brazillians, but no big global online community events
    again. In my opinion online MiniDebConfs can be a great way to develop
    our community and we should spend some further energy into this, but
    hey! This isn't a platform so let me back out of talking about the
    future as I see it...

    Despite all the adversity that we faced together, the Debian 11 release
    ended up being quite good. It happened about a month or so later than
    what we ideally would've liked, but it was a solid release nonetheless.
    It turns out that for quite a few people, staying inside for a few
    months to focus on Debian bugs was quite productive, and Debian 11 ended
    up being a very polished release.

    During this time period we also had to deal with a previous Debian
    Developer that was expelled for his poor behaviour in Debian, who
    continued to harass members of the Debian project and in other free
    software communities after his expulsion. This ended up being quite a
    lot of work since we had to take legal action to protect our community,
    and eventually also get the police involved. I'm not going to give him
    the satisfaction by spending too much time talking about him, but you
    can read our official statement regarding Daniel Pocock here:

    https://www.debian.org/News/2021/20211117

    In late 2021 and early 2022 we also discussed our general resolution
    process, and had two consequent votes to address some issues that have
    affected past votes:

    * https://www.debian.org/vote/2021/vote_003
    * https://www.debian.org/vote/2022/vote_001

    In my first term I addressed our delegations that were a bit behind, by
    the end of my last term all delegation requests are up to date. There's
    still some work to do, but I'm feeling good that I get to hand this
    over to the next DPL in a very decent state. Delegation updates can be
    very deceiving, sometimes a delegation is completely re-written and it
    was just 1 or 2 hours of work. Other times, a delegation updated can
    contain one line that has changed or a change in one team member that
    was the result of days worth of discussion and hashing out differences.

    I also received quite a few requests either to host a service, or to
    pay a third-party directly for hosting. This was quite an admin
    nightmare, it either meant we had to manually do monthly reimbursements
    to someone, or have our TOs create accounts/agreements at the multiple providers that people use. So, after talking to a few people about
    this, we founded the DebianNet team (we could've admittedly chosen a
    better name, but that can happen later on) for providing hosting at two different hosting providers that we have agreement with so that people
    who host things under debian.net have an easy way to host it, and then
    at the same time Debian also has more control if a site maintainer goes
    MIA.

    More info:

    https://wiki.debian.org/Teams/DebianNet

    You might notice some Openstack mentioned there, we had some intention
    to set up a Debian cloud for hosting these things, that could also be
    used for other additional Debiany things like archive rebuilds, but
    these have so far fallen through. We still consider it a good idea and hopefully it will work out some other time (if you're a large company
    who can sponsor few racks and servers, please get in touch!)

    - DebConf22 and Debian 12 era:

    DebConf22 was the first time we returned to an in-person DebConf. It
    was a bit smaller than our usual DebConf - understandably so,
    considering that there were still COVID risks and people who were at
    high risk or who had family with high risk factors did the sensible
    thing and stayed home.

    After watching many MiniDebConfs online, I also attended my first ever MiniDebConf in Hamburg. It still feels odd typing that, it feels like I should've been at one before, but my location makes attending them
    difficult (on a side-note, a few of us are working on bootstrapping a
    South African Debian community and hopefully we can pull off
    MiniDebConf in South Africa later this year).

    While I was at the MiniDebConf, I gave a talk where I covered the
    evolution of firmware, from the simple e-proms that you'd find in old
    printers to the complicated firmware in modern GPUs that basically
    contain complete operating systems- complete with drivers for the
    device their running on. I also showed my shiny new laptop, and
    explained that it's impossible to install that laptop without non-free
    firmware (you'd get a black display on d-i or Debian live). Also that
    you couldn't even use an accessibility mode with audio since even that
    depends on non-free firmware these days.

    Steve, from the image building team, has said for a while that we need
    to do a GR to vote for this, and after more discussion at DebConf, I
    kept nudging him to propose the GR, and we ended up voting in favour of
    it. I do believe that someone out there should be campaigning for more
    free firmware (unfortunately in Debian we just don't have the resources
    for this), but, I'm glad that we have the firmware included. In the
    end, the choice comes down to whether we still want Debian to be
    installable on mainstream bare-metal hardware.

    At this point, I'd like to give a special thanks to the ftpmasters,
    image building team and the installer team who worked really hard to
    get the changes done that were needed in order to make this happen for
    Debian 12, and for being really proactive for remaining niggles that
    was solved by the time Debian 12.1 was released.

    The included firmware contributed to Debian 12 being a huge success,
    but it wasn't the only factor. I had a list of personal peeves, and as
    the hard freeze hit, I lost hope that these would be fixed and made
    peace with the fact that Debian 12 would release with those bugs. I'm
    glad that lots of people proved me wrong and also proved that it's
    never to late to fix bugs, everything on my list got eliminated by the
    time final freeze hit, which was great! We usually aim to have a
    release ready about 2 years after the previous release, sometimes there
    are complications during a freeze and it can take a bit longer. But due
    to the excellent co-ordination of the release team and heavy lifting
    from many DDs, the Debian 12 release happened 21 months and 3 weeks
    after the Debian 11 release. I hope the work from the release team
    continues to pay off so that we can achieve their goals of having
    shorter and less painful freezes in the future!

    Even though many things were going well, the ongoing usr-merge effort highlighted some social problems within our processes. I started typing
    out the whole history of usrmerge here, but it's going to be too long
    for the purpose of this mail. Important questions that did come out of
    this is, should core Debian packages be team maintained? And also about
    how far the CTTE should really be able to override a maintainer. We had
    lots of discussion about this at DebConf22, but didn't make much
    concrete progress. I think that at some point we'll probably have a GR
    about package maintenance. Also, thank you to Guillem who very
    patiently explained a few things to me (after probably having have to
    done so many times to others before already) and to Helmut who have
    done the same during the MiniDebConf in Hamburg. I think all the
    technical and social issues here are fixable, it will just take some
    time and patience and I have lots of confidence in everyone involved.

    UsrMerge wiki page: https://wiki.debian.org/UsrMerge

    - DebConf 23 and Debian 13 era:

    DebConf23 took place in Kochi, India. At the end of my Bits from the
    DPL talk there, someone asked me what the most difficult thing I had to
    do was during my terms as DPL. I answered that nothing particular stood
    out, and even the most difficult tasks ended up being rewarding to work
    on. Little did I know that my most difficult period of being DPL was
    just about to follow. During the day trip, one of our contributors,
    Abraham Raji, passed away in a tragic accident. There's really not
    anything anyone could've done to predict or stop it, but it was
    devastating to many of us, especially the people closest to him. Quite
    a number of DebConf attendees went to his funeral, wearing the DebConf
    t-shirts he designed as a tribute. It still haunts me when I saw his
    mother scream "He was my everything! He was my everything!", this was
    by a large margin the hardest day I've ever had in Debian, and I really
    wasn't ok for even a few weeks after that and I think the hurt will be
    with many of us for some time to come. So, a plea again to everyone,
    please take care of yourself! There's probably more people that love
    you than you realise.

    A special thanks to the DebConf23 team, who did a really good job
    despite all the uphills they faced (and there were many!).

    As DPL, I think that planning for a DebConf is near to impossible, all
    you can do is show up and just jump into things. I planned to work with
    Enrico to finish up something that will hopefully save future DPLs some
    time, and that is a web-based DD certificate creator instead of having
    the DPL do so manually using LaTeX. It already mostly works, you can
    see the work so far by visiting https://nm.debian.org/person/ACCOUNTNAME/certificate/ and replacing
    ACCOUNTNAME with your Debian account name, and if you're a DD, you
    should see your certificate. It still needs a few minor changes and a
    DPL signature, but at this point I think that will be finished up when
    the new DPL start. Thanks to Enrico for working on this!

    Since my first term, I've been trying to find ways to improve all our accounting/finance issues. Tracking what we spend on things, and
    getting an annual overview is hard, especially over 3 trusted
    organisations. The reimbursement process can also be really tedious,
    especially when you have to provide files in a certain order and
    combine them into a PDF. So, at DebConf22 we had a meeting along with
    the treasurer team and Stefano Rivera who said that it might be
    possible for him to work on a new system as part of his Freexian work.
    It worked out, and Freexian funded the development of the system since
    then, and after DebConf23 we handled the reimbursements for the
    conference via the new reimbursements site:

    https://reimbursements.debian.net

    It's still early days, but over time it should be linked to all our TOs
    and we'll use the same category codes across the board. So, overall,
    our reimbursement process becomes a lot simpler, and also we'll be able
    to get information like how much money we've spent on any category in
    any period. It will also help us to track how much money we have
    available or how much we spend on recurring costs. Right now that needs
    manual polling from our TOs. So I'm really glad that this is a big long-standing problem in the project that is being fixed.

    For Debian 13, we're waving goodbye to the KFreeBSD and mipsel ports.
    But we're also gaining riscv64 and loongarch64 as release
    architectures! I have 3 different RISC-V based machines on my desk here
    that I haven't had much time to work with yet, you can expect some blog
    posts about them soon after my DPL term ends!

    As Debian is a unix-like system, we're affected by the [Year 2038
    problem], where systems that uses 32 bit time in seconds since 1970 run
    out of available time and will wrap back to 1970 or have other
    undefined behaviour. A detailed [wiki page] explains how this works in
    Debian, and currently we're going through a rather large transition to
    make this possible.

    [Year 2038 problem] https://simple.wikipedia.org/wiki/Year_2038_problem
    [wiki page] https://wiki.debian.org/ReleaseGoals/64bit-time

    I believe this is the right time for Debian to be addressing this,
    we're still a bit more than a year away for the Debian 13 release, and
    this provides enough time to test the implementation before 2038 rolls
    along.

    Of course, big complicated transitions with dependency loops that
    causes chaos for everyone would still be too easy, so this past weekend
    (which is a holiday period in most of the west due to Easter weekend)
    has been filled with dealing with an upstream bug in xz-utils, where a
    backdoor was placed in this key piece of software. An [Ars Technica]
    covers it quite well, so I won't go into all the details here. I
    mention it because I want to give yet another special thanks to
    everyone involved in dealing with this on the Debian side. Everyone
    involved, from the ftpmasters to security team and others involved were
    super calm and professional and made quick, high quality decisions.
    This also lead to the archive being frozen on Saturday, this is the
    first time I've seen this happen since I've been a DD, but I'm sure
    next week will go better!

    [Ars Technica] https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/

    == Looking forward ==

    It's really been an honour for me to serve as DPL. It might well be my
    biggest achievement in my life. Previous DPLs range from prominent
    software engineers to game developers, or people who have done things
    like complete Iron Man, run other huge open source projects and are
    part of big consortiums. Ian Jackson even authored dpkg and is now
    working on the very interesting [tag2upload service]!

    [tag2upload service]
    https://peertube.debian.social/w/pav68XBWdurWzfTYvDgWRM

    I'm a relative nobody, just someone who grew up as a poor kid in South
    Africa, who just really cares about Debian a lot. And, above all, I'm
    really thankful that I didn't do anything major to screw up Debian for
    good.

    Not unlike learning how to use Debian, and also becoming a Debian
    Developer, I've learned a lot from this and it's been a really valuable
    growth experience for me.

    I know I can't possible give all the thanks to everyone who deserves
    it, so here's a big big thanks to everyone who have worked so hard and
    who have put in many, many hours to making Debian better, I consider
    you all heroes!

    -Jonathan

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEExyA8CpIGcL+U8AuxsB0acqyNyaEFAmYK20UACgkQsB0acqyN yaHjUQ//RJ69lxV7drXR6hiEmxGep/SQAi7p/tHE2qFtHqvjFvbsdT87v/5jRRaX t9jIwaU025femEu1bVlsG76e2q8yvqm4dICLMeVTi+PQwhspSIKHu/aVgTOpH+I3 4el/DxfTFzjQgRHSK6ORmG09lAtDzq/Ig4e7mfaG4nQ9AJkaHen6bQZ45QSbQ4EF seOrXgN5KPNytaF34LLsRrNOqbLrl+yonzv3lFhnYn5z1NTC55YMB0I+60Sr1uf+ e2uQVxT6U43t++0811reyToR9vhAkrwjQoV1tydaTLYF11e7oHUwKqfn0FObiNX5 onEu0/w7YxXTFJSOGXUHaDUbYaIkteEWacx1hsQAprBzd3aoHcRFhK/9g2NJ02Zk DPhC0g8zD0ueUB6FdNfqSupc0K1miYjBIcmomxdQCIXvghZa/EBHD/4pkAIJSDmO X5EV+E3hW5Wmeci36a/L4KB9b7WhSbpJU/TWuq7PjZprt2wwRO94wIe0Zi86VxGm Yngy7N/stp4RnOOdaDd9bQDXSPKxtyVi2HTmhsOPrwMRU81K1sQUOkXEarHrn5DV 3P/ap+5vBX7UKSMvVUcA46Sh+OjoRZEUxO7Eo4qRAvAZC3gb+p/W5O6eDqFkbwfb IpDY+i5J9HRp+8PJtZVW5pB/cxLlnQypixy9wC7m2qr5huHjJUo=
    =E9b0
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to All on Fri May 9 07:20:01 2025
    Dear Debian community,

    This is bits from the DPL for April.


    End of 10
    =========

    I am sure I was speaking in the interest of the whole project when
    joining the "End of 10" campaign[e1]. Here is what I wrote to the
    initiators:

    Hi Joseph and all drivers of the "End of 10" campaign,

    On behalf of the entire Debian project, I would like to say that we
    proudly join your great campaign. We stand with you in promoting Free
    Software, defending users' freedoms, and protecting our planet by
    avoiding unnecessary hardware waste.

    Thank you for leading this important initiative.

    Andreas Tille
    Debian Project Leader

    [e1] https://endof10.org/


    I have some goals I would like to share with you for my second term.


    Ftpmaster delegation
    ====================

    This splits up into tasks that can be done before and after Trixie release.

    Before Trixie:


    1. Reducing Barriers to DFSG Compliance Checks ----------------------------------------------

    Back in 2002[f1], Debian established a way to distribute cryptographic
    software in the main archive, whereas such software had previously been restricted to the non-US archive. One result of this arrangement which influences our workflow is that all packages uploaded to the NEW queue
    must remain on the server that hosts it[f2]. This requirement means that members of the ftpmaster team must log in to that specific machine,
    where they are limited to a restricted set of tools for reviewing
    uploaded code.

    This setup may act as a barrier to participation--particularly for
    contributors who might otherwise assist with reviewing packages for DFSG compliance. I believe it is time to reassess this limitation and work
    toward removing such hurdles.

    In October last year, we had some initial contact with SPI's legal
    counsel, who noted that US regulations around cryptography have been
    relaxed somewhat in recent years (as of 2021). This suggests it may now
    be possible to revisit and potentially revise the conditions under which
    we manage cryptographic software in the NEW queue.

    I plan to investigate this further. If you have expertise in software or
    export control law and are interested in helping with this topic, please
    get in touch with me.

    The ultimate goal is to make it easier for more people to contribute to ensuring that code in the NEW queue complies with the DFSG.

    [f1] https://lists.debian.org/debian-devel-announce/2002/03/msg00019.html
    [f2] https://salsa.debian.org/debconf-team/public/data/dc24/-/blob/main/etherpad/txt/154-meet-the-ftpteam.txt#L165-175


    2. Discussing Alternatives
    --------------------------

    My chances to reach out to other distributions remained limited.
    However, regarding the processing of new software, I learned that
    OpenSUSE uses a Git-based workflow that requires five "LGTM" approvals
    from a group of trusted developers. As far as I know, Fedora follows a
    similar approach.

    Inspired by this, a recent community initiative--the Gateway to NEW project--enables peer review of new packages for DFSG compliance before
    they enter the NEW queue. This effort allows anyone to contribute by
    reviewing packages and flagging potential issues in advance via Git
    [g1]. I particularly appreciate that the DFSG review is coupled with CI, allowing for both license and technical evaluation.

    While this process currently results in some duplication of work--since
    final reviews are still performed by the ftpmaster team--it offers a
    valuable opportunity to catch issues early and improve the overall
    quality of uploads. If the community sees long-term value in this
    approach, it could serve as a basis for evolving our workflows.
    Integrating it more closely into DAK could streamline the process, and
    we've recently seen that merge requests reflecting community suggestions
    can be accepted promptly.[g2]

    For now, I would like to gather opinions about how such initiatives
    could best complement the current NEW processing, and whether greater
    consensus on trusted peer review could help reduce the burden on the
    team doing DFSG compliance checks. Submitting packages for review and
    automated testing before uploading can improve quality and encourage
    broader participation in safeguarding Debian's Free Software principles.

    My explicit thanks go out to the Gateway to NEW team for their valuable
    and forward-looking contribution to Debian.

    [g1] https://lists.debian.org/debian-devel/2025/04/msg00067.html
    https://salsa.debian.org/newgateway-team
    [g2] https://salsa.debian.org/ftp-team/dak/-/merge_requests/286


    3. Documenting Critical Workflows
    ---------------------------------

    Past ftpmaster trainees have told me that understanding the full set of ftpmaster workflows can be quite difficult. While there is some useful documentation--thanks in particular to Sean Whitton for his work on
    documenting NEW processing rules[d1]--many other important tasks carried
    out by the ftpmaster team remain undocumented or only partially so.

    Comprehensive and accessible documentation would greatly benefit current
    and future team members, especially those onboarding or assisting in
    specific workflows. It would also help ensure continuity and
    transparency in how critical parts of the archive are managed.

    If such documentation already exists and I have simply overlooked it, I
    would be happy to be corrected. Otherwise, I believe this is an area
    where we need to improve significantly. Volunteers with a talent for
    writing technical documentation are warmly invited to contact me--I'd be
    happy to help establish connections with ftpmaster team members who are
    willing to share their knowledge so that it can be written down and
    preserved.

    [d1] https://salsa.debian.org/ftp-team/manpages/-/blob/master/doc/ftp-new.7.man?ref_type=heads



    Once Trixie is released (hopefully before DebConf):


    4. Split of the Ftpmaster Team into DFSG and Archive Teams ----------------------------------------------------------

    As discussed during the "Meet the ftpteam" BoF at DebConf24[s1], I would
    like to propose a structural refinement of the current Ftpmaster team
    by introducing two different delegated teams:

    1. DFSG Team
    2. Archive Team (responsible for DAK maintenance and process tooling,
    including releases)

    (Alternative name suggestions are, of course, welcome.) The primary task
    of the DFSG team would be the processing of the NEW queue and ensuring
    that packages comply with the DFSG. The Archive team would focus on maintaining DAK and handling the technical aspects of archive
    management.

    I am aware that, in the recent past, the ftpmaster team has decided not
    to actively seek new members. While I respect the autonomy of each team,
    the resulting lack of a recruitment pipeline has led to some friction
    and concern within the wider community, including myself. As Debian
    Project Leader, it is my responsibility to ensure the long-term
    sustainability and resilience of our project, which includes fostering
    an environment where new contributors can join and existing teams remain effective and well-supported. Therefore, even if the current team does
    not prioritize recruitment, I will actively seek and encourage new
    contributors for both teams, with the aim of supporting openness and collaboration.

    This proposal is not intended as criticism of the current team's
    dedication or achievements--on the contrary, I am grateful for the hard
    work and commitment shown, often under challenging circumstances. My
    intention is to help address the structural issues that have made
    onboarding and specialization difficult and to ensure that both teams
    are well-supported for the future.

    I also believe that both teams should regularly inform the Debian
    community about the policies and procedures they apply. I welcome any suggestions for a more detailed description of the tasks involved, as
    well as feedback on how best to implement this change in a way that
    supports collaboration and transparency.

    My intention with this proposal is to foster a more open and effective
    working environment, and I am committed to working with all involved to
    ensure that any changes are made collaboratively and with respect for
    the important work already being done.

    I'm aware that the ideas outlined above touch on core parts of how
    Debian operates and involve responsibilities across multiple teams.
    These are not small changes, and implementing them will require
    thoughtful discussion and collaboration.

    To move this forward, I've registered a dedicated BoF for DebConf. To
    make the most of that opportunity, I'm looking for volunteers who feel committed to improving our workflows and processes. With your help, we
    can prepare concrete and sensible proposals in advance--so the limited
    time of the BoF can be used effectively for decision-making and consensus-building.

    In short: I need your help to bring these changes to life. From my
    experience in my last term, I know that when it truly matters, the
    Debian community comes together--and I trust that spirit will guide us
    again.

    Please also note: we had a "Call for volunteers" five years ago[s2], and
    much of what was written there still holds true today. I've been told
    that the response back then was overwhelming--but that training such a
    large number of volunteers didn't scale well. This time, I hope we can
    find a more sustainable approach: training a few dedicated people first,
    and then enabling them to pass on their knowledge. This will also be a
    topic at the DebCamp sprint.

    [s1] https://salsa.debian.org/debconf-team/public/data/dc24/-/blob/main/etherpad/txt/154-meet-the-ftpteam.txt#L67-74
    [s2] https://lists.debian.org/debian-devel-announce/2020/03/msg00003.html



    Dealing with Dormant Packages
    =============================

    Debian was founded on the principle that each piece of software should
    be maintained by someone with expertise in it--typically a single,
    responsible maintainer. This model formed the historical foundation of
    Debian's packaging system and helped establish high standards of quality
    and accountability. However, as the project has grown and the number of packages has expanded, this model no longer scales well in all areas.
    Team maintenance has since emerged as a practical complement, allowing
    multiple contributors to share responsibility and reduce
    bottlenecks--depending on each team's internal policy.

    While working on the Bug of the Day initiative[d1], I observed a
    significant number of packages that have not been updated in a long
    time. In the case of team-maintained packages, addressing this is often straightforward: team uploads can be made, or the team can be asked
    whether the package should be removed. We've also identified many
    packages that would fit well under the umbrella of active teams, such as language teams like Debian Perl and Debian Python, or blends like Debian
    Games and Debian Multimedia. Often, no one has taken action--not because
    of disagreement, but simply due to inattention or a lack of initiative.

    In addition, we've found several packages that probably should be
    removed entirely. In those cases, we've filed bugs with pre-removal
    warnings, which can later be escalated to removal requests.

    When a package is still formally maintained by an individual, but shows
    signs of neglect (e.g., no uploads for years, unfixed RC bugs, failing autopkgtests), we currently have three main tools:

    1. The MIA process[d2], which handles inactive or unreachable
    maintainers.
    2. Package Salvaging[d3], which allows contributors to take over
    maintenance if conditions are met.
    3. Non-Maintainer Uploads (NMUs)[d4], which are limited to specific,
    well-defined fixes (which do not include things like migration
    to Salsa).

    These mechanisms are important and valuable, but they don't always allow
    us to react swiftly or comprehensively enough. Our tools for identifying packages that are effectively unmaintained are relatively weak, and the thresholds for taking action are often high.

    The Package Salvage team is currently trialing a process we've
    provisionally called "Intend to NMU" (ITN). The name is admittedly questionable--some have suggested alternatives like "Intent to
    Orphan"--and discussion about this is ongoing on debian-devel [d5]. The mechanism is intended for situations where packages appear inactive but
    aren't yet formally orphaned, introducing a clear 21-day notice period
    before NMUs, similar in spirit to the existing ITS process. The
    discussion has sparked suggestions for expanding NMU rules[d6].

    While it is crucial not to undermine the autonomy of maintainers who
    remain actively involved, we also must not allow a strict interpretation
    of this autonomy to block needed improvements to obviously neglected
    packages.

    To be clear: I do not propose to change the rights of maintainers who
    are clearly active and invested in their packages. That model has served
    us well. However, we must also be honest that, in some cases,
    maintainers stop contributing--quietly and without transition plans. In
    those situations, we need more agile and scalable procedures to uphold
    Debian's high standards.

    To that end, I've registered a BoF session for DebConf25 to discuss
    potential improvements in how we handle dormant packages. These
    discussions will be prepared during a sprint at DebCamp, where I hope to
    work with others on concrete ideas.

    Among the topics I want to revisit is my proposal from last November on debian-devel, titled "Barriers between packages and other people"[d7].
    While the thread prompted substantial discussion, it understandably
    didn't lead to consensus. I intend to ensure the various viewpoints are
    fairly summarised--ideally by someone with a more neutral stance than myself--and, if possible, work toward a formal proposal during the
    DebCamp sprint to present at the DebConf BoF.

    My hope is that we can agree on mechanisms that allow us to act more effectively in situations where formerly very active volunteers have,
    for whatever reason, moved on. That way, we can protect both Debian's
    quality and its collaborative spirit.

    [d0] https://salsa.debian.org/qa/tiny_qa_tools/-/wikis/Tiny-QA-tasks#bug-of-the-day
    [d2] https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.en.html#dealing-with-inactive-and-or-unreachable-maintainers
    [d3] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#package-salvaging
    [d4] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#non-maintainer-uploads-nmus
    [d5] https://lists.debian.org/debian-devel/2025/05/msg00082.html + following discussion
    [d6] https://lists.debian.org/debian-devel/2025/05/msg00144.html
    [d7] https://lists.debian.org/debian-devel/2024/12/msg00101.html



    Building Sustainable Funding for Debian
    =======================================

    Debian incurs ongoing expenses to support its
    infrastructure--particularly hardware maintenance and upgrades--as well as
    to fund in-person meetings like sprints and mini-DebConfs. These
    investments are essential to our continued success: they enable
    productive collaboration and ensure the robustness of the operating
    system we provide to users and derivative distributions around the
    world.

    While DebConf benefits from generous sponsorship, and we regularly
    receive donated hardware, there is still considerable room to grow our financial base--especially to support less visible but equally critical activities. One key goal is to establish a more constant and predictable
    stream of income, helping Debian plan ahead and respond more flexibly to emerging needs.

    This presents an excellent opportunity for contributors who may not be
    involved in packaging or technical development. Many of us in Debian are engineers first--and fundraising is not something we've been trained to
    do. But just like technical work, building sustainable funding requires expertise and long-term engagement.

    If you're someone who's passionate about Free Software and has
    experience with fundraising, donor outreach, sponsorship acquisition, or nonprofit development strategy, we would deeply value your help.
    Supporting Debian doesn't have to mean writing code. Helping us build a
    steady and reliable financial foundation is just as important--and could
    make a lasting impact.


    Kind regards
    Andreas.


    PS: In April I also planted my 5000th tree and while this is
    off-topic here I'm proud to share this information with my
    fellow Debian friends.
    https://fam-tille.de/baeume_pflanzen/index.html#statistik


    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmgdj3MACgkQV4oElNHG RtGIQQ//QpvO4B9uXbAfvGolsgebLfhOSaLuq9+GNiEPtffPimK/UuASH9x59Lwj lls01Fvdg9jh5hMV6f82jTDdxhjJZvbV1XCiVtCIjPx3IExHHoeNGGnHZtWxudmK O9Jvffjmv9t/HOF4/bIYFjykS2U1R9SMAxpGyEK6EAXpn59MvbR0Vw519EusKBxu o8FB7wMW3JXfcQDEMa1U/y5BHoQZQ6KMi7c7zrrS/GuH+nvSCtnpks9M+IR8wdfq DH/6x0lGxY3q5f/5YZkV1RVko1IGWveTWJmd1rp515PJTdkh8XDl+9/+NzIP6Gpf yI+SJ2i+XM8DczmWC8FYCml9I4mxlh/1yN9DKM00uXfjIOXhTP5e5vuQ1dx8712e XZu7FvN+1BY2jSYpQPo9FQQI4CSqg3p8YBm6f9obbWGDuWYZVMvQ0vo3+rtDkOL4 rMbNHf+rEzHNM49i7b1bu3FnrLPEaBy5gkF1E8/IDgKKqUjBXqQFi+UrD/bTA5rY 4/udTCF7fcQ15xCE+dZqqMN3yknSxXxQzKkXrGSXBIHnzqguIyHhRhwl+TJVHu/O 83l1wHZiiwZMMbbUg7BuIWRWsX2zxIDN5ncQPt+HUXsnJq1Y8NcrX541atFAD1Kb X4+GC4O3wIxaWKT1YWyQm7cLpllUNVTx3A37TWBgwvzG3aeWWFk=
    =Y0NG
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to All on Mon Jun 2 17:40:01 2025
    Dear Debian community,

    This is bits from the DPL for May.


    Interpretation of DFSG on Artificial Intelligence (AI) Models =============================================================

    First of all, I would like to thank Mo Zhou for the extensive work on
    drafting a General Resolution titled "Interpretation of DFSG on
    Artificial Intelligence (AI) Models"[ai01]. He dedicated a significant
    amount of time and effort to preparing this proposal, engaging in early discussions and gathering feedback long before bringing it to the
    project. Despite this thorough preparation, the unfolding discussion
    quickly revealed just how deep and multifaceted the issue really is.

    Choice 1 was titled: "AI models released under open source license
    without original training data or program are not seen as
    DFSG-compliant".

    The discussion had many dimensions:
    * Practical implications, such as what packages might become
    uninstallable or instantly RC-buggy [ai02][ai03];
    * Technical concerns, including the feasibility of distributing very
    large files across Debian infrastructure;
    * Ethical considerations, such as how to weigh the rights of those
    whose data may have been used for training.

    Throughout the conversation, there appeared to be two broad currents of thought: one emphasizing pragmatism, and the other focused more on
    ethical principles. Russ Allbery perhaps captured this tension best when
    he wrote[ai04]: "We absolutely should base our rules on what's best for
    human beings, not corporate constructs. That is the entire point of the
    free software movement."

    Two alternative proposals were developed—one by Thorsten Glaser[ai05],
    and another by Sam Hartman[ai06]—but it became clear that no broad
    consensus had yet emerged within the community.

    Recognizing this, Mo Zhou has withdrawn the original proposal [ai07],
    and Sam Hartman has withdrawn his alternative proposal as well [ai08].

    This topic is far from resolved, but that’s not a failure—it’s a sign of just how new and difficult this territory is. To continue the discussion productively, I suggest that we meet in person at DebConf (with a remote participation option), to work on a revised and better-informed draft,
    in order to do more groundwork on preparing the discussion and start to
    explore alternatives. These are questions we must address as a project,
    and doing so will take both time and collective effort.

    [ai01] https://www.debian.org/vote/2025/vote_002
    [ai02] https://lists.debian.org/debian-vote/2025/04/msg00114.html
    [ai03] https://lists.debian.org/debian-vote/2025/04/msg00113.html
    [ai04] https://lists.debian.org/debian-vote/2025/05/msg00137.html
    [ai05] https://lists.debian.org/debian-vote/2025/04/msg00118.html
    [ai06] https://lists.debian.org/debian-vote/2025/05/msg00027.html
    [ai07] https://lists.debian.org/debian-vote/2025/05/msg00105.html
    [ai08] https://lists.debian.org/debian-vote/2025/05/msg00111.html



    SPI Report
    ==========

    SPI is issuing yearly reports about its activities[sp01]. I have
    submitted the following report for Debian which should be available
    from the SPI website soon:


    During 2024, the Debian project continued to grow and evolve, thanks
    to the dedication of its large volunteer community and contributors
    from around the world.

    We made substantial progress toward Debian 13 ("Trixie"), with key
    foundational changes implemented during the year. Most notably, we
    completed the transition to 64-bit time_t on 32-bit architectures,
    preparing Debian for the Year 2038 and ensuring long-term platform
    viability. In addition, the long-running effort to merge /usr—unifying
    system directory layouts—was finalized, simplifying package maintenance
    and bringing Debian in line with other major distributions.

    In line with our release management practices, we published regular
    point releases for both Debian 11 ("bullseye") and Debian 12
    ("bookworm"). These updates included important security fixes and bug
    fixes to improve the reliability of our stable distributions.

    We welcomed 22 new Debian Developers and 30 new Debian Maintainers in
    2024. These new contributors help ensure the sustainability and
    diversity of our project, and we’re excited to see many of them already
    actively engaging across teams and packaging efforts.

    The Debian community remained vibrant, with a successful DebConf24 held
    in Busan, South Korea. This was accompanied by several MiniDebConfs
    around the globe, continuing our effort to reach contributors and users
    worldwide.

    For regular updates and news about what’s going on in the Debian
    project, visit the "Bits from Debian" blog and follow us on the
    Fediverse and other platforms.

    Submitted by Andreas Tille


    [sp01] https://spi-inc.org/corporate/annual-reports/


    Kind regards
    Andreas.


    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmg9w4EACgkQV4oElNHG RtECeQ//bYA5kwlgqubwTb/xONcWvN3R3KbkQG+AdSmR7FUUWulSpzJ3SZIRslvS 0ZsRMe9KRkroB5kh/4UNEsIrt44Wxjv9bHU1lzxoxkTDI24VzvhceX1DdER445IF fjXk8sWU54TA5fJNcPqAEJoA9thQpZvkLjCkvLzHR585t3+g6kQJ4mFzRRQOPxMB LFsjzEW8wt/Q/KyTDZRGxuw1NVyxmJLmFUQbrSpRyjrS6o7UJFXj6ocX5WShgTiR 02DkG2ClH6C52s37pgVBYqTndTKnS/5zJsl8OQ808TPn5Ly7RaNxuSV97gVoCLFc BHLfwlS/DMAirSi/3289QYIfLeFoE+3IvlzcAi5fefRE4fBZ8RsJoPrfjaTnchfF jWj650A2MeKvo0WWSn1NIAYH+phG9wcUg+3QRMDLkcqk9G8r3A7CKWo2aOyeugBE G4dMhfa2Vj9sS7YosopdYAPvmyoeqgHb8NTa+IeiuvUzyzWmSOAxoHnOeSwfrMBi 0iJrDDOiWmVF9A8BC26IFjVALDhxyaqzJBfrppoa8eabp30Niisem37qFDNo/ubX 8sCIKSej94DSYez0CnX7WYOfRu4x7iuaRBIQE2uQ/WK8nniWZn1gr1+FTbwOrvC1 XAT1wUiVCtO407Dpw2oK8gdwcYzv8htN6/7y3myDT3XiuV6IwPY=
    =i526
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to All on Tue Jun 3 09:40:01 2025
    XPost: linux.debian.devel

    Hello,

    for the folsk not involved with Debian GNU/Linux but monitoring it as journalists for example I have to ask.

    Am 02.06.2025 17:30 schrieb Andreas Tille:
    Interpretation of DFSG on Artificial Intelligence (AI) Models

    What is "DFSG"?

    SPI Report

    What is "SPI"?
    Even the linked page on spi-inc.org does not explain what it is.

    And by the way: "AI" is a marketing and sci-fi term. It is a thing that
    does not exist. Experts, like Debian people are, shouldn't IMHO not take
    over marketing terms but use correct technical terms; e.g. large
    language models (LLM). "AI" does wake expectations at users.

    Regards,
    Christian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to All on Fri Jul 4 06:00:01 2025
    Dear Debian community,

    This is bits from the DPL for June.


    The Challenge of Mentoring Newcomers
    ====================================

    In June there was an extended discussion about the ongoing challenges
    around mentoring newcomers in Debian. As many of you know, this is a
    topic I’ve cared about deeply--long before becoming DPL. In my view, the issue isn’t just a matter of lacking tools or needing to “try harder” to attract contributors. Anyone who followed the discussion will likely
    agree that it’s more complex than that.

    I sometimes wonder whether Debian’s success contributes to the problem.
    From the outside, things may appear to “just work”, which can lead to
    the impression: “Debian is doing fine without me--they clearly have everything under control.” But that overlooks how much volunteer effort
    it takes to keep the project running smoothly.

    We should make it clearer that help is always needed--not only in
    packaging, but also in writing technical documentation, designing web
    pages, reaching out to upstreams about license issues, finding sponsors,
    or organising events. (Speaking from experience, I would have
    appreciated help in patiently explaining Free Software benefits to
    upstream authors.) Sometimes we think too narrowly about what newcomers
    can do, and also about which tasks could be offloaded from overcommitted contributors.

    In fact, one of the most valuable things a newcomer can contribute is
    better documentation. Those of us who’ve been around for years may be
    too used to how things work--or make assumptions about what others
    already know. A person who just joined the project is often in the best position to document what’s confusing, what’s missing, and what they
    wish they had known sooner.

    In that sense, the recent “random new contributor’s experience” posts [m01] might be a useful starting point for further reflection. I think
    we can learn a lot from positive user stories, like this recent
    experience of a newcomer adopting the courier package. I'm absolutely
    convinced that those who just found their way into Debian have valuable perspectives--and that we stand to learn the most from listening to
    them.

    We should also take seriously what Russ Allbery noted in the discussion: “This says bad things about the project's sustainability and I think
    everyone knows that.” [m02] Volunteers move on--that’s normal and
    expected. But it makes it all the more important that we put effort into keeping Debian's contributor base at least stable, if not growing.


    [m01] https://lists.debian.org/debian-devel/2025/06/msg00055.html
    https://lists.debian.org/debian-devel/2025/06/msg00105.html
    [m02] https://lists.debian.org/debian-devel/2025/06/msg00073.html


    Project-wide LLM budget for helping people ==========================================

    Lucas Nussbaum has volunteered to handle the paperwork and submit a
    request on Debian’s behalf to LLM providers [l01], aiming to secure project-wide access for Debian Developers. If successful, every DD will
    be free to use this access--or not--according to their own preferences.


    [l01] https://lists.debian.org/debian-devel/2025/06/msg00060.html


    Kind regards
    Andreas.


    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmhnUYIACgkQV4oElNHG RtFQRQ//S+EjrFYp30w0tlcoG/8aC9hCbHnUFq2eS9ysaX8fktyhOjTK6f89ziyd BKDC2Qokb3TOzWf9Kd1TkDfJjh16YNo6iw3AuFMxOFAs1j+rXw9Wk2B5pb0jmK8/ PF6kL4dzC0FSPIwldyQLXY0cFjwiTu87aytnUIovvhvGOYVy6jzeEXv6ks/CnMea ZsEH+B9s+XMmko5bFcwmyQ9UbwdkZsyRuEfX+TBYbu3uMCkH5mneLay1axTHg03P jhCezP5Ee7oP97t4Zl0+2hWEwszFgjnIBicxNcP6Crn8IRhMiJQzWMIKeLuxro4F rrPV7Z6UoHv5wYksRlXZzTQyDEMdmGKZUTCV0SIW/qflRUEulKLs/UmN/a9KVuvZ 5fqG+VETk4aDQABAgdpk0O75yFACWWe71pNHx7lsvZSM0lF7dKi/5GD0dNmEpyf1 au5Dka1NMg3Rm1sqt3yIWqxGY+fJmhH3HwRSGIF2EOW/iA6Wt0CpjzW4VISUh+W+ gXiipDaFWaR1X/5+BT2ajE7tPVmG9Ei+iGctHhxUnK1RkgymQS5qdy9JRcYxF5HC SxtaITkkKhPD9f4bJva3N5+NPCXIUEHeZ+zXxGZcm4jeuKgnOrN8sNf46HMBze+Z 95vZ0goWoGrWdsbBO/zEOTPsMV4fIMuOfzPOTdfRyeIkjiEWr/A=
    =GuE2
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to All on Fri Aug 1 09:00:01 2025
    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.


    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmiMY9UACgkQV4oElNHG RtG+GxAAkL8QvLZMgIKmLTDHY1lIUkzWZndjESzXj7eazNFS2S06SKom6pUkV9oq EPN9A/MQh6IlkPocB6j6GFIwvBSKyTlS8UKhAezRIlJ972vcWHIeaVjWv353SeEl g1S/EZ5VkvIXqqQTfoF1cSB5qUtdt4rNwyCK2fhlBQQ+8Iy17DhP5dMTMkze9QT+ zcn+sfQvSWsStBFne9l/4M27Fn+cWPEqweUrI/Oo1i7EAHbDEjJRanyAFtARCKSC tFJMeQVKShzSjoUwiVsAAUum5U+6q1Ima+7i3Vqk4kfHRCRe/zpSAtJDDkh+hTel q6FAcxvk98s1bto64EdbSAWo9ul1d68KnrRFH3C07Pm6GAcfLKnvAHWFHe2q/80p hH+H0aMzZqntEX7lHvrXkzrionB8PtDYtwKFbQDHsa2vkmtW57wt8H2vScZVVM4Y lPQHvLhLci1vvl/Dsx3P12qrs9N5vFZgc6jGYBudRmUVlefZzKanoqdPEoahKxy2 hBMX/FOIdNauXettCkQ2OgoudsTlI5HCtA6kiykeOCr0+GCgScJUhGLQXHYzm2kd F45/htrwNGDw6jDhQ0PS3UuEV60ml0D+fLlWQOHJu9zfc+O+ukOdXo/jA5KNpsSv L2d8Mct1YPH5cvGZ8tXmaKRLQYD7MO2DFHfbgh5rRIBmer6bEQw=
    =6gEI
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)