• Bits from DPL

    From Andreas Tille@21:1/5 to All on Thu May 2 07:20:01 2024
    Hi,

    keeping my promise for monthly bits, here's a quick snapshot of my first
    ten days as DPL.

    Special thanks to Jonathan for an insightful introduction that left less
    room for questions. His introduction covered my first tasks like expense approval and CTTE member appointments thoroughly. Although I made a
    visible oversight by forgetting to exclude Simon McVittie <smcv> from
    the list, whose term has ended[0], I'm committed to learning from this
    mistake. In future I'll prioritize thorough proofreading to ensure
    accuracy.

    Part of my "work" was learning what channels I need to subscribe and
    adjust my .procmailrc and .muttrc took some time.

    Recently I had my first press interview. I had to answer a couple of
    prepared questions for Business IT News[1]. It seems journalists are
    always on the lookout for unique angles. When asked if humility is a new
    trait for DPLs, my response would be a resounding "No." In my
    experience, humility is a common quality among DPLs I've encountered,
    including Jonathan.

    One of my top priorities is reaching out to all our dedicated and
    appointed teams, including those managing critical infrastructure. I've
    begun with the CTTE, Salsa Admins and Debian Snapshot. Everything
    appears to be in order with the CTTE team. I'm waiting for response
    from Salsa and Snapshot, which is fine given the recent contact.

    I was pointed out to the fact that lintian is in an unfortunate state as
    Axel Beckert confirmed on the lintian maintainers list[2]. It turns out
    that bug #1069745 of magics-python should not have been undetected for
    a long time if lintian bug #677078[3] would have been fixed. It seems
    obvious to me that lintian needs more work to fulfill its role as
    reliably policy checker to ensure our high level of packaging quality.
    In any case thanks a lot to Axel who is doing his best but it seems
    urgent to me to find some more person-power for this task. Any volunteer
    to lend some helping hand in the lintian maintainers team?

    On 2024-04-30 I gave my first talk "Bits from greenhorn DPL" online
    at MiniDebConf Brasil in Belo Horizonte. The Q&A afterwards stired
    some flavours of the question: "What can Debian Brasil do better?"
    My answer was always in a way: Given your great activity in now
    organising the fifth MiniDebConf you are doing pretty well and I have
    no additional hints for the moment.

    Kind regards
    Andreas.

    [0] https://lists.debian.org/debian-devel-announce/2024/04/msg00010.html
    [1] https://itwire.com/business-it-news/open-source/new-debian-leader-brings-an-unusual-trait-to-the-job-humility.html
    [2] https://lists.debian.org/debian-lint-maint/2024/04/msg00010.html
    [3] https://bugs.debian.org/677078
    lintian: Check for Architecture: all in Perl, Python, Ruby etc. packages
    Date: Mon, 11 Jun 2012 16:15:53 +0300



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

    iQIzBAABCAAdFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmYzIU4ACgkQV4oElNHG RtFM0RAAkV5o0QlNHdwC6op34+MfDja8gKbL77PYv20BNlCJl9eTnGyNzjtMEmeX WJou3s+Te/4c9/JBNRGT6+fcYLtq7dgNuFfrgsLIWt9GdmwaQH1exCLP+s/G8/ji XCTrEtJqOK+4PKjmwHxINhVTScqcfs3LCl4wYLBrTzz73Gi7IlCMK0Co/py3kdVO udjO6/ug5KBy+1N+CrUHEWJ6bc1PDU4TJKcVQ2TYUIPYw6NsAT+irbNFVZlN8mVt w7HWWaVNSJoEynqRh6Uj4yOAnOdH8ZpzIXQFLjNGz2VpxLiVAvSuvSacYZzRlFiJ rdTDUqg/dU6yDoTu9V44YUJmcfihwoYJMxcSKYzmCij6ZU4Ag3oWb6YBrUGIVIM7 cbzNBFfsQ2YCZoZdfa//A0+nK8wQiD+UC/Q9HYwSG8E4bFyWHyXLMgVhrGP0s798 3/LmzRzjxgPmCEMlDPONLMdE+cu2PCPjdFFmoDHX2zYfjDEC5lv1nI5qYOQ+a/J7 G8rOuj5/aLjHAhhzQM67NcpR//3Ifl467g9FlG6k0HG9G871Ah99wrCrG3W1pQDg LsavSlxL1tF7wVid7mdNh5utsv3Gpp1NvcUv+TaHEXiCyQNeIDYv8uEQr9gRJIju cg8UoIPLWjjWB99ILTZVbmbB7IGbio/jPR9gbawfRLtjPob9Ba0=
    =xOnB
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to All on Sat Jun 1 10:00:01 2024
    Hi,

    in May, I was on vacation for a while, partly with unexpectedly weak
    internet connection. Anyway I tried to do some DPL work which I
    summarise in these bits.


    Meeting policy
    --------------

    in connection with MiniDebConf Berlin there was some discussion about
    what expense per attendee of some in person meeting is OK. Quoting
    Chris Lamb from his "Bits from the DPL (March 2018)"[meet1]:

    Debian is willing to reimburse up to 100 USD for expenses to attend Bug
    Squashing Parties (BSPs). If there are no BSPs near to you, please help
    organise one!

    More detailed information about sponsoring Debian events can be found in Wiki[meet2] which is based on some mail from Jonathan Carter on from 2020[meet3]. I subscribe to what was said before since I consider in
    person meetings very important for Debian.


    Use of AI-generated content
    ---------------------------

    There was an interesting discussion about policy on use of AI-generated
    content in Debian on Debian project list[ai1]. In Tiago's[ai2] summary
    of the discussion he stated: "Apparently we are far from a consensus on
    an official Debian position regarding the use of generative AI as a
    whole in the project." I've read this thread with much interest but
    have nothing more intelligent to say than some well educated
    contributors to this thread. I simply recommend it as some interesting reading.


    Installer
    ---------

    If I would have known that once I'm elected for DPL a dream seems to
    come true that chances are really good we get Blends in the
    installer[bl1] (bug #186085) I would have run earlier vor DPL. ;-P


    Contacting teams
    ----------------

    Despite being mostly on vac I've started to contact some teams and will continue in June to cover more teams. It is a bit too early to summarize
    the responses I've received. Whether I've managed to contact a team yet
    or need more time, I'd like to point out that I've registered a BoF for DebConf24 in Busan with the following description:

    This BoF is an attempt to gather as much as possible teams inside
    Debian to exchange experiences, discuss workflows inside teams, share
    their ways to attract newcomers etc.

    Each participant team should prepare a short description of their work
    and what team roles (“openings”) they have for new contributors. Even
    for delegated teams (membership is less fluid), it would be good to
    present the team, explain what it takes to be a team member, and what
    steps people usually go to end up being invited to participate. Some
    other teams can easily absorb contributions from salsa MRs, and at some
    point people get commit access. Anyway, the point is that we work on the
    idea that the pathway to become a team member becomes more clear from an
    outsider point-of-view.

    I'm sure not everybody will be able to travel this distance but it would
    be great if you would at least consider joining that BoF remotely. I'll
    care for a somehow TimeZone aware scheduling - if needed we'll organise
    two BoFs to match all time zones. I'm also aware that we have pretty
    different teams and it might make sense to do some infrastructure
    related BoF with your team and other teams that are caring for Debian infrastructure.

    Kind regards
    Andreas.


    [meet1] https://lists.debian.org/debian-devel-announce/2018/03/msg00007.html [meet2] https://wiki.debian.org/HostingBSP#Sponsorships
    [meet3] https://lists.debian.org/debian-project/2020/08/msg00050.html

    [ai1] https://lists.debian.org/debian-project/2024/05/msg00000.html

    [bl1] https://lists.debian.org/debian-blends/2024/05/msg00001.html

    --
    https://fam-tille.de

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

    iQIzBAABCAAdFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmZa0zsACgkQV4oElNHG RtENYQ//VcPW64VAfZZ0bYn9NATcSB/AXqxiHJzRsMNM6udWl1EvboxN2nS1s3r1 hIW0BOF1UMOsqEbPW9cfMKbaGcsvonvSPSdxfJCUraE0RfGn1fJLK8ojvoLDNjbY pGvFN/hrKwP/m4Pp1BNP8QrBx5I1GPLtUGtVEVZxGMrnS8sRRINm2nOzXysGCrVj 8yM2lgI42cTQxl0Dxez5kznC/imfN7ilfcEu2afY5wm/gbsnzh08zT+c2BeYBPvz V2IUDUaWCtcs5+VGL+tdtwtBsIvf7pWcYnHuZOo8TghdcJilGte9+pw6/RXJ0TZk Sgidy6HNMJBho5t6gxbBpAPEYp+itJ0tctZEttIYkwQbFqdu+c08yfevR0BKm2p2 cIAfZaYPbgX3wj/nmmOKlDAR8ClDU/Ahd2OAHDJKCIRQ+6pWN6SbGsWuQI0qZUZg gErXt/vrjunnxeMhGclF4K2credx60QlZ51VULlwyOkyOh1d0xbLe/hCmjrH/pC3 GzyY8YWydT1xeBg7Uc81bluyCb588y97pM9bZiVYQLeeexq7cTWc66h/FsRGHMJX eeibWZl3eDt+MBdo3haUARR4XF29kNPRWFWTtWT9IljfsaJLcuiUkXJlKpfg2l+C om73S1bhuQgXBr6YlrswDTgR+eLlHdHyqvH4+TzW9eHtmCRSq0I=
    =cgAW
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to All on Mon Jul 1 20:30:01 2024
    Dear Debian community,


    Statement on Daniel Pocock
    --------------------------

    The Debian project has successfully taken action to secure its
    trademarks and interests worldwide, as detailed in our press
    statement[tm1]. I would like to personally thank everyone in the
    community who was involved in this process. I would have loved for you
    all to have spent your volunteer time on more fruitful things.

    [tm1] https://www.debian.org/News/2024/20240606


    Debian Boot team might need help
    --------------------------------

    I think I've identified the issue that finally motivated me to contact
    our teams: for a long time, I have had the impression that Debian is
    driven by several "one-person teams" (to varying extents of individual influence and susceptibility to burnout). As DPL, I see it as my task to
    find ways to address this issue and provide support.

    I received private responses from Debian Boot team members, which
    motivated me to kindly invite volunteers to some prominent and highly
    visible fields of work that you might find personally challenging. I
    recommend subscribing to the Debian Boot mailing list[boot1] to see
    where you might be able to provide assistance.

    [boot1] https://lists.debian.org/debian-boot/


    /usr-merge
    ----------

    Helmut Grohne confirmed[usrmrg1] that the last remaining packages
    shipping aliased files inside the package set relevant to debootstrap
    were uploaded. Thanks a lot for Helmut and all contributors that
    helped to implement DEP17[usrmrg2].

    [usrmrg1] https://lists.debian.org/debian-devel/2024/06/msg00034.html
    [usrmrg2] https://dep-team.pages.debian.net/deps/dep17/


    Contacting more teams
    ---------------------

    I'd like to repeat that I've registered a BoF for DebConf24 in Busan
    with the following description:

    This BoF is an attempt to gather as much as possible teams inside
    Debian to exchange experiences, discuss workflows inside teams, share
    their ways to attract newcomers etc.

    Each participant team should prepare a short description of their work
    and what team roles (“openings”) they have for new contributors. Even
    for delegated teams (membership is less fluid), it would be good to
    present the team, explain what it takes to be a team member, and what
    steps people usually go to end up being invited to participate. Some
    other teams can easily absorb contributions from salsa MRs, and at some
    point people get commit access. Anyway, the point is that we work on the
    idea that the pathway to become a team member becomes more clear from an
    outsider point-of-view.

    I'm lagging a bit behind my team contacting schedule and will not manage
    to contact every team before DebConf. As a (short) summary, I can draw
    some positive conclusions about my efforts to reach out to teams. I was
    able to identify some issues that were new to me and which I am now
    working on. Examples include limitations in Salsa and Salsa CI. I
    consider both essential parts of our infrastructure and will support
    both teams in enhancing their services.

    Some teams confirmed that they are basically using some common
    infrastructure (Salsa team space, mailing lists, IRC channels) but that
    the individual members of the team work on their own problems without
    sharing any common work. I have also not read about convincing
    strategies to attract newcomers to the team, as we have established, for instance, in the Debian Med team.


    DebConf attendance
    ------------------

    The amount of money needed to fly people to South Korea was higher than
    usual, so the DebConf bursary team had to make some difficult decisions
    about who could be reimbursed for travel expenses. I extended the budget
    for diversity and newcomers, which enabled us to invite some additional contributors. We hope that those who were not able to come this year can
    make it next year to Brest or to MiniDebConf Cambridge[dc1] or
    Toulouse[dc2].

    [dc1] https://lists.debian.org/debian-devel-announce/2024/06/msg00002.html [dc2] https://lists.debian.org/debian-devel-announce/2024/05/msg00001.html


    tag2upload
    ----------

    On June 12, Sean Whitton requested comments on the debian-vote list
    regarding a General Resolution (GR) about tag2upload[t2u1]. The
    discussion began with technical details but unfortunately, as often
    happens in long threads, it drifted into abrasive language, prompting
    the community team to address the behavior of an opponent of the GR
    supporters. After 560 emails covering technical details, including a
    detailed security review by Russ Allbery[t2u2], Sean finally proposed
    the GR[t2u3] on June 27, 2024 (two weeks after requesting comments).

    Firstly, I would like to thank the drivers of this GR and acknowledge
    the technical work behind it, including the security review. I am
    positively convinced that Debian can benefit from modernizing its infrastructure, particularly through stronger integration of Git into
    packaging workflows.

    Sam Hartman provided some historical context[t2u4], noting that this
    discussion originally took place five years ago with no results from
    several similarly lengthy threads. My favorite summary of the entire
    thread was given by Gregor Herrmann[t2u5], which reflects the same gut
    feeling I have and highlights a structural problem within Debian that
    hinders technical changes. Addressing this issue is definitely a matter
    for the Debian Project Leader, and I will try to address it during my
    term.

    At the time of writing these bits, a proposal from ftpmaster[t2u6],
    which is being continuously discussed, might lead to a solution.
    I was also asked to extend the GR discussion periods[t2u7] which I
    will do in separate mail.

    [t2u1] https://lists.debian.org/debian-vote/2024/06/msg00000.html
    [t2u2] https://www.eyrie.org/~eagle/notes/debian/tag2upload.html
    [t2u3] https://lists.debian.org/debian-vote/2024/06/msg00561.html
    [t2u4] https://lists.debian.org/debian-vote/2024/06/msg00581.html
    Historic links to the same topic in 2019
    https://lists.debian.org/debian-devel/2019/07/msg00501.html
    https://lists.debian.org/debian-devel/2019/08/msg00407.html
    https://bugs.debian.org/932753
    [t2u5] https://lists.debian.org/debian-vote/2024/06/msg00583.html
    [t2u6] https://lists.debian.org/debian-vote/2024/06/msg00602.html
    [t2u7] https://lists.debian.org/debian-vote/2024/07/msg00006.html


    Talk: Debian GNU/Linux for Scientific Research ----------------------------------------------

    I was invited to have a talk[t1] in the Systems-Facing Track of
    University of British Columbia (who is sponsoring rack space for several
    Debian servers). I admit it felt a bit strange to me after working more
    than 20 years for establishing Debian in scientific environments to be
    invited to such a talk "because I'm DPL". ;-)

    [t1] https://people.debian.org/~tille/talks/20240620_using_debian_in_science/index_en.html


    Kind regards
    Andreas.



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

    iQIzBAABCAAdFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmaC80gACgkQV4oElNHG RtHVHBAAmYV3rK5zO68Rx3e3igaIcGuJMUfGZ72R32fU2d2BZE3eNcpYGRP7Nv/K /oKyLGlEQtVNbOC6mQppyiQTp/qQU7Rn+NH8t6oxOvPpBcaGgmVJhGfWxTNds2Y4 8+84H9rQ7OzZn6P+Ae3VscPvg78VdJ8Uv6SsiWcSjiniWzVi2GRMCASfC0NwVP/W aP43HXMoUAuyvDHGFcfRA2lBplx2+t6pep3svDTwFRk2u/Cx5KyL561bwdibNMHF EfhWxFhZdUe9ua7CIJQ2zQUow5t70405yzi6p/JpeuHj8c38ARcCed9tDkttByiO ruz8DbHJY74sqWviVZLlJaNqEj4hkIc9zr+XNNtYWDVzUZBVAD0zk33cjj8IYTNP MIjoA3tz1kpOyWTur0+FoswPPvU2/uVqwV6OsNPjFlRNYUHYkh6Vba6SseCMV/+v 7LZc2xV0Eo0jpmNQHCDP4AIz0a7OQ5orAy4AErXG0BCNwwFivDqIi7rbCCuW2T6C AMR60sCjuK8Vp4fzJPNxK3RdpvYArQYxoFBgQOSisvfiOn7b52JWsBiG/EAmcmAt JpPL3ftxX7hXdvS9KQAkk1aivr1Y5o7crD1sZV4D6IdKDHlf+K58CPTKnbqs3VEf wvpMML9OTRKQYbnh1sOuWA3I2ieGmbQ+j5HRQeunEE54RqJ56R0=
    =eLyf
    -----END PGP SIGNATURE-----

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

    this are my bits from DPL written at my last day at another great
    DebConf.

    DebConf attendance
    ------------------

    At the beginning of July, there was some discussion with the bursary and content team about sponsoring attendees. The discussion continued at DebConf[da1]. I do not have much experience with these discussions. My
    summary is that while there is an honest attempt to be fair to everyone,
    it did not seem to work for all, and some critical points for future
    discussion remained. In any case, I'm thankful to the bursary team for
    doing such a time-draining and tedious job.

    [da1] https://debconf24.debconf.org/talks/38-debconf-bursary-team-bof/


    Popular packages not yet on Salsa at all ----------------------------------------

    Otto Keklinen did some interesting investigation about "Popular
    packages not yet on Salsa at all" [ps1]. I think I might provide some
    more up to date list soon by some UDD query which considers more recent
    uploads than the trends data soon. For instance wget was meanwhile
    moved to Salsa (thanks to Nol Kthe for this).

    [ps1] https://alioth-lists.debian.net/pipermail/debian-salsa-ci/2024-July/000134.html


    Keep on contacting more teams
    -----------------------------

    I kept on contacting teams in July. Despite I managed to contact way
    less teams than I was hoping I was able to present some conclusions in
    the "Debian Teams exchange" BoF[te1] and Slide 16/23 of my "Bits from
    the DPL" talk[te2]. I intend to do further contacts next months.

    [te1] https://debconf24.debconf.org/talks/87-debian-teams-exchange/
    [te2] https://people.debian.org/~tille/talks/20240730_debconf_dpl/bits.pdf#page=47


    Nominating Jeremy Bcha for GNOME Advisory Board ------------------------------------------------

    I've nominated Jeremy Bcha to GNOME Advisory Board. Jeremy has
    volunteered to represent Debian at GUADEC [gb2] in Denver.

    [gb1] https://wiki.gnome.org/AdvisoryBoard
    [gb2] https://events.gnome.org/event/209/


    DebCamp / DebConf
    -----------------

    I attended DebCamp starting from 22.7. evening and had a lot of fun with
    other attendees. As always DebConf is some important event nearly
    every year for me. I enjoyed Korean food, Korean bath, nature at the
    costline and other things.

    I had a small event without video coverage "Creating web galleries
    including maps from a geo-tagged photo collection"[dc1]. At least two attendees of this workshop confirmed success in creating their own web galleries.

    I used DebCamp and DebConf for several discussions. My main focus was on discussions with FTP master team members Luke Faraone, Sean Whitton, and Utkarsh Gupta. I'm really happy that the four of us absolutely agree on
    some proposed changes to the structure of the FTP master team, as well
    as changes that might be fruitful for the work of the FTP master team
    itself and for Debian developers regarding the processing of new
    packages.

    My explicit thanks go to Luke Faraone, who gave a great introduction to
    FTP master work in their BoF[dc2]. It was very instructive for the
    attending developers to understand how the FTP master team checks
    licenses and copyright and what workflow is used for accepting new
    packages.

    In the first days of DebConf, I talked to representatives of DebConf
    platinum sponsor WindRiver, who announced the derivative eLxr[dc3]. I
    warmly welcome this new derivative and look forward to some great
    cooperation. I also talked to the representative of our gold sponsor, Microsoft.

    My first own event was the Debian Med BoF[dc4]. I'd like to repeat that
    it might not only be interesting for people working in medicine and microbiology but always contains some hints how to work together in a
    team.

    As said above I was trying to summarise some first results of my team
    contacts and got some further input from other teams in the "Debian
    Teams exchange" BoF[te1].

    Finally, I had my "Bits from DPL" talk[dc5]. I received positive
    responses from attendees as well as from remote participants, which
    makes me quite happy. For those who were not able to join the events
    on-site or remotely, the videos of all events will be available on the
    DebConf site soon. I'd like to repeat the explicit need for some
    volunteers to join the Lintian team. I'd also like to point out the
    "Tiny tasks" initiative I'd like to start (see below).

    BTW, if someone might happen to solve my quiz for the background images
    there is a summary page in my slides[dc6] which might help to assign
    every slide to some DebConf. I could assume that if you pool your
    knowledge you can solve more than just the simple ones. Just let me
    know if you have some solution. You can add numbers to the rows and
    letters to the columns and send me:

    2000/2001: Uv + Wx
    2002: not attended
    2003: Yz
    2004: not attended
    2005:
    2006: not attended
    2007:
    ...
    2024: A1

    This list provides some additional information for DebConfs I did not
    attend and when no video stream was available. It also reminds you about
    the one I uncovered this year and that I used two images from 2001 since
    I did not have one from 2000. Have fun reassembling good memories.

    [dc1] https://debconf24.debconf.org/talks/153-creating-web-galleries-including-maps-from-a-geo-tagged-photo-collection/
    [dc2] https://debconf24.debconf.org/talks/154-meet-the-ftpteam/
    [dc3] https://www.windriver.com/blog/Introducing-eLxr
    [dc4] https://debconf24.debconf.org/talks/21-debian-med-bof/
    [dc5] https://debconf24.debconf.org/talks/20-bits-from-the-dpl/
    [dc6] https://people.debian.org/~tille/talks/20240730_debconf_dpl/bits.pdf#page=60


    Tiny tasks: Bug of the day
    --------------------------

    As I mentioned in my "Bits from DPL" talk[dc5], I'd like to start a
    "Tiny tasks" effort within Debian. The first type of tasks will be the
    "Bug of the day" initiative[tt1]. For those who would like to join,
    please join the corresponding Matrix channel[tt2]. I'm curious to see
    how this might work out and am eager to gain some initial experiences
    with newcomers. I won't be available until next Monday, as I'll start
    traveling soon and have a family event (which is why I need to leave
    DebConf today after the formal dinner).

    [tt1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
    [tt2] https://matrix.to/#/#debian-tiny-tasks:matrix.org


    Kind regards from DebConf in Busan
    Andreas.

    --
    https://fam-tille.de

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

    iQIzBAABCAAdFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmarGg8ACgkQV4oElNHG RtFrhg//X4HN7rc2i6qRIsol3aTkze6H3LtZx9/jtJDdoKsx0YUW7rD6mLpAWj2r 1r1u67ClHv3idZo/uxaiNG9RB+VzxcqsnmlCfGSE/3kuOCadTfiV0UAeCkgGUeyM A/uSaoEsy8IoAwZANdeXMvck7QsvVmTHb2mK0VMLa5M6jpnBkSs5ibq8XHKi3/nM i7BN3dnMtZ2Z0gPLfX5ATt1WlmhlsZSMEWRkgNTevipdfBGm+hP3ks36Ju3D3zsn ZPHzazdwjAtgXgzBfAL8aOqsctY5i74RfTvHwGRWxUi/RC4D9Gzxm/cCN6i539lK NuRJ2KtOK7vV4QEsZQfeAfZ1UXh9r1cKZCIDSi77S9ig+uEY6SO1F6aNw4WYYmdi StAi/S4wjfPxBgioEDuJNTiypxTrlCqSvvSjtlDdAtaDzQXVH8lUIp9LVm2F4Zgm Fwvts6umAl8RRQvUw+Y1ZzaP0agJnGm/K2ux/dOxIVmR/qcChZw6nUt8Hy88OKWX puPOJ/UQSWaDxLNURKbWJ3EQV9Dj1xFhdjiqpRelUmOy3hVGfYBkM+Lw0O0V/9FV y/RU4HVfKYBStjEDdMP6+XZFus1FKPukQM0Oxy6sjWj6v5gNMWtq8SBSnkqiJj35 Bndwc3p3/AaxbylAGiJzfNgQjzVK7RwRof7/EenNL//thGINmNc=
    =wlqb
    -----END PGP SIGNATURE-----

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

    this are my bits from DPL for August.


    Happy Birthday Debian
    ---------------------

    On 16th of August Debian celebrated its 31th birthday. Since I'm
    unable to write a better text than our great publicity team I'm
    simply linking to their article for those who might have missed it:

    https://bits.debian.org/tag/birthday.html


    Removing more packages from unstable
    ------------------------------------

    Helmut Grohne argued for more aggressive package removal and sought
    consensus on a way forward[ru1]. He provided six examples of processes
    where packages that are candidates for removal are consuming valuable person-power. I’d like to add that the Bug of the Day initiative (see
    below) also frequently encounters long-unmaintained packages with popcon
    votes sometimes as low as zero, and often fewer than ten.

    Helmut's email included a list of packages that would meet the suggested removal criteria. There was some discussion about whether a popcon vote
    should be included in these criteria, with arguments both for[ru2] and against[ru3] it. Although I support including popcon, I acknowledge that
    Helmut has a valid point in suggesting it be left out.

    While I’ve read several emails in agreement, Scott Kitterman made a
    valid point[ru4]: "I don't think we need more process. We just need
    someone to do the work of finding the packages and filing the bugs." I
    agree that this is crucial to ensure an automated process doesn’t lead
    to unwanted removals. However, I don’t see "someone" stepping up to file
    RM bugs against other maintainers' packages. As long as we have strict ownership of packages, many people are hesitant to touch a package, even
    for fixing it. Asking for its removal might be even less well-received. Therefore, if an automated procedure were to create RM bugs based on
    defined criteria, it could help reduce some of the social pressure.

    In this aspect the opinion of Niels Thykier[ru5] is interesting: "As
    much as I want automation, I do not mind the prototype starting as a semi-automatic process if that is what it takes to get started."

    The urgency of the problem to remove packages was put by Charles
    Plessy[ru6] into the words: "So as of today, it is much less work to
    keep a package rotting than removing it." My observation when trying to
    fix the Bug of the Day exactly fits this statement.

    I would love for this discussion to lead to more aggressive removals
    that we can agree upon, whether they are automated, semi-automated, or
    managed by a person processing an automatically generated list
    (supported by an objective procedure). To use an analogy: I’ve found
    that every image collection improves with aggressive pruning. Similarly,
    I’m convinced that Debian will improve if we remove packages that no
    longer serve our users well.

    [ru1] https://lists.debian.org/debian-devel/2024/08/msg00298.html
    [ru2] https://lists.debian.org/debian-devel/2024/08/msg00362.html
    [ru3] https://lists.debian.org/debian-devel/2024/08/msg00354.html
    [ru4] https://lists.debian.org/debian-devel/2024/08/msg00314.html
    [ru5] https://lists.debian.org/debian-devel/2024/08/msg00306.html
    [ru6] https://lists.debian.org/debian-devel/2024/08/msg00320.html


    DEP14 / DEP18
    -------------

    There are two DEPs that affect our workflow for maintaining packages—particularly for those who agree on using Git for Debian
    packages. DEP-14 recommends a standardized layout for Git packaging repositories, which benefits maintainers working across teams and makes
    it easier for newcomers to learn a consistent repository structure.

    DEP-14 stalled for various reasons. Sam Hartman suspected[de2] it might
    be because 'it doesn't bring sufficient value.' However, the assumption
    that git-buildpackage is incompatible with DEP-14 is incorrect, as
    confirmed by its author, Guido Günther[de3]. As one of the two key tools
    for Debian Git repositories (besides dgit) fully supports DEP-14, though
    the migration from the previous default is somewhat complex.

    Some investigation into mass-converting older formats to DEP-14 was
    conducted by the Perl team, as Gregor Hermann pointed out.[de4].

    The discussion about DEP-14 resurfaced with the suggestion of DEP-18.
    Guido Günther proposed the title[de5] 'Encourage Continuous Integration
    and Merge Request-Based Collaboration for Debian Packages,' which more accurately reflects the DEP's technical intent.

    Otto Kekäläinen, who initiated DEP-18 (thank you, Otto), provided a good summary of the current status[de6]. He also assembled a very helpful
    overview of Git and GitLab usage in other Linux distros[de7].

    [de1] https://dep-team.pages.debian.net/deps/dep14/
    [de2] https://lists.debian.org/debian-devel/2024/08/msg00229.html
    [de3] https://lists.debian.org/debian-devel/2024/08/msg00212.html
    [de4] https://lists.debian.org/debian-devel/2024/08/msg00232.html
    [de5] https://salsa.debian.org/dep-team/deps/-/merge_requests/8#note_520426 [de6] https://lists.debian.org/debian-devel/2024/08/msg00433.html
    [de7] https://lists.debian.org/debian-devel/2024/08/msg00419.html


    More Salsa CI
    -------------

    As a result of the DEP-18 discussion, Otto Kekäläinen suggested
    implementing Salsa CI for our top popcon packages[ci1].

    I believe it would be a good idea to enable CI by default across Salsa
    whenever a new repository is created.[ci2]

    [ci1] https://lists.debian.org/debian-devel/2024/08/msg00318.html
    [ci2] https://lists.debian.org/debian-devel/2024/08/msg00370.html


    Progress in Salsa migration
    ---------------------------

    In my campaign, I stated[sm1] that I aim to reduce the number of
    packages maintained outside Salsa to below 2,000. As of March 28, 2024,
    the count was 2,368. Today, it stands at 2,187[sm2].

    After a third of my DPL term (OMG), we've made significant progress,
    reducing the amount in question (369 packages) by nearly half. I'm
    pleased with the support from the DDs who moved their packages to Salsa.
    Some packages were transferred as part of the Bug of the Day initiative
    (see below).

    [s1] https://lists.debian.org/debian-vote/2024/03/msg00057.html
    [sm2] UDD query:
    SELECT DISTINCT count(*) FROM sources WHERE release = 'sid' and vcs_url not like '%salsa%' ;


    Bug of the Day
    --------------

    As announced in my 'Bits from the DPL' talk at DebConf[bd1], I started
    an initiative called Bug of the Day[bd2]. The goal is to train newcomers
    in bug triaging by enabling them to tackle small, self-contained QA
    tasks. We have consistently identified target packages and resolved at
    least one bug per day, often addressing multiple bugs in a single
    package.

    In several cases, we followed the Package Salvaging procedure outlined
    in the Developers Reference[bd3]. Most instances were either welcomed by
    the maintainer or did not elicit a response. Unfortunately, there was
    one exception where the recipient of the Package Salvage bug expressed significant dissatisfaction. The takeaway is to balance formal
    procedures with consideration for the recipient’s perspective.

    I'm pleased to confirm that the Matrix channel[bd4] has seen an increase
    in active contributors. This aligns with my hope that our efforts would
    attract individuals interested in QA work. I’m particularly pleased
    that, within just one month, we have had help with both fixing bugs and improving the code that aids in bug selection.

    As I aim to introduce newcomers to various teams within Debian, I also
    take the opportunity to learn about each team's specific policies
    myself. I rely on team members' assistance to adapt to these policies. I
    find that gaining this practical insight into team dynamics is an
    effective way to understand the different teams within Debian as DPL.

    Another finding from this initiative, which aligns with my goal as DPL,
    is that many of the packages we addressed are already on Salsa but have
    not been uploaded, meaning their VCS fields are not published. This
    suggests that maintainers are generally open to managing their packages
    on Salsa. For packages that were not yet on Salsa, the move was
    generally welcomed.

    [bd1] https://debconf24.debconf.org/talks/20-bits-from-the-dpl/
    [bd2] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
    [bd3] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
    [bd4] https://matrix.to/#/#debian-tiny-tasks:matrix.org


    Publicity team wants you
    ------------------------

    The publicity team has decided to resume regular meetings to coordinate
    their efforts. Given my high regard for their work, I plan to attend
    their meetings as frequently as possible, which I began doing with the
    first IRC meeting.

    During discussions with some team members, I learned that the team could
    use additional help. If anyone interested in supporting Debian with non-packaging tasks reads this, please consider introducing yourself to debian-publicity@lists.debian.org. Note that this is a publicly archived mailing list, so it's not the best place for sharing private
    information.


    Kind regards
    Andreas.


    --
    https://fam-tille.de

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

    iQIzBAABCAAdFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmbV2G4ACgkQV4oElNHG RtGPyw/+NGT45lJ1ETC/90qRgviKlD9WB9rizggTKzNxaBdBj88C7hXJYVWDQCdG Y7A5ocTGGufip6jL/rd9UGVuQZen4DhzhFQ+Qz/8u4v35hvauHFfciU8IlE1JsS+ 9LHR5ifF+9ykz3AWmwREYABFuECMAYF0ZgcmcVcAUPHwC9t6rOxB8/TSGQfZXzoV r7J4427peQTqdd/M9JEuOXi4OTTaexmFMG+TP5bLmOjzzQApiDWNAhs1Snfxan4e aujVSSKYHK633Ygofjck2C1N7SGriWHCrI8ftYyOLlpp2A3wtq6Z6oYQLriwD2OW G+SSFjIu2eMgEgNo/NZllj8GfWfXw/AzuZ35z+rzUCOIp/yCDN1rQT5YT/xuVZQ+ KOtWjdoJmhkXGBf4p5W5WrWB5N0mbbqRvzf5JONVXevoYgIx8JqxvHP3Va8fss58 DigHLkjwObQ1k8W4aeVuyqNO8JxJdpA87OOTQhDp9RIpCIDk9wtOHyLV/BgInW8j qpsZI0mSLg/rpC8mb9LHkxludS42ubCBIdTldGr0gepnkk58JOaLBwchEBqS8+bv TBWaW8iPF0HqAaFlZtPiUMc0q0wDWSikwczbCBTXaYpI4DvwAuqUkL95f57vwXsX WY/xHR/KnYozlUFpoxOk9RWAVzodnirA9JZD+RP1VMplZj8LTUo=
    =jYIR
    -----END PGP SIGNATURE-----

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

    this are my bits from DPL for September.


    New lintian maintainer
    ----------------------

    I'm pleased to welcome Louis-Philippe Vronneau as a new Lintian
    maintainer. He humorously acknowledged his new role, stating,
    "Apparently I'm a Lintian maintainer now." [li1] I remain confident that
    we can, and should, continue modernizing our policy checker, and I see
    this as one important step toward that goal.

    [li1] https://lists.debian.org/debian-devel/2024/09/msg00014.html


    SPDX name / license tools
    -------------------------

    There was a discussion about deprecating the unique names for DEP-5 and migrating to fully compliant SPDX names[sp1].

    Simon McVittie wrote[sp2]: "Perhaps our Debian-specific names *are*
    better, but the relevant question is whether they are *sufficiently*
    better to outweigh the benefit of sharing effort and specifications with
    the rest of the world (and I don't think they are)." Also Charles
    Plessy sees the value of deprecating the Debian ones and align on
    SPDX.[sp3]

    The thread on debian-devel list contains several practical hints for
    writing debian/copyright files.

    [sp1] https://lists.debian.org/debian-devel/2024/09/msg00140.html
    [sp2] https://lists.debian.org/debian-devel/2024/09/msg00150.html
    [sp3] https://lists.debian.org/debian-devel/2024/09/msg00163.html


    proposal: Hybrid network stack for Trixie -----------------------------------------

    There was a very long discussion on debian-devel list about the network
    stack on Trixi that started in July[nw1] and was continued in end of August[nw2] / beginning of September. The discussion was also covered
    on LWN[nw3]. It continued in a "proposal: Hybrid network stack for Trixie"
    by Lukas Mrdian[nw4].

    [nw1] https://lists.debian.org/debian-devel/2024/07/msg00098.html
    [nw2] https://lists.debian.org/debian-devel/2024/08/msg00317.html
    [nw3] https://lwn.net/Articles/989055/
    [nw4] https://lists.debian.org/debian-devel/2024/09/msg00240.html


    Contacting teams:
    -----------------

    I continued reaching out to teams in September. One common pattern I've
    noticed is that most teams lack a clear strategy for attracting new contributors. Here's an example snippet from one of my outreach emails,
    which is representative of the typical approach:

    Q: Do you have some strategy to gather new contributors for your team?
    A: No.
    Q: Can I do anything for you?
    A: Everything that can help to have more than 3 guys :-D

    Well, only the first answer, "No," is typical. To help the JavaScript
    team, I'd like to invite anyone with JavaScript experience to join the
    team's mailing list and offer to learn and contribute. While I've only
    built a JavaScript package once, I know this team has developed
    excellent tools that are widely adopted by others. It's an active and
    efficient team, making it a great starting point for those looking to
    get involved in Debian. You might also want to check out the "Little
    tutorial for JS-Team beginners"[ct2].

    Given the lack of a strategy to actively recruit new contributors--a
    common theme in the responses I've received--I recommend reviewing my
    talk from DebConf23 about teams[ct3]. The Debian Med team would have
    struggled significantly in my absence (I've paused almost all work with
    the team since becoming DPL) if I hadn't consistently focused on
    bringing in new members. I'm genuinely proud of how the team has managed
    to keep up with the workload (thank you, Debian Med team!). Of course, onboarding newcomers takes time, and there's no guarantee of long-term
    success, but if you don't make the effort, you'll never find out.

    [ct1] https://lists.debian.org/debian-js/
    [ct2] https://wiki.debian.org/Javascript/Tutorial
    [ct3] https://debconf23.debconf.org/talks/32-teams-newcomers-and-numbers/


    OS underpaid
    ------------

    The Register, in its article titled "Open Source Maintainers Underpaid,
    Swamped by Security, Going Gray"[os1], summarizes the 2024 State of the
    Open Source Maintainer Report. I find this to be an interesting read,
    both in general and in connection with the challenges mentioned in the
    previous paragraph about finding new team members.

    [os1] https://www.theregister.com/2024/09/18/open_source_maintainers_underpaid/

    Kind regards
    Andreas.

    --
    https://fam-tille.de

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

    iQIzBAABCAAdFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmcD/2cACgkQV4oElNHG RtE0sA/+OfA32mHB0maoui8l4SAcYC2DiFVrvTNmKZHQ1p+0nlP2XWSzC/TvoCjM 9Ec6wBtK2MaU0+eqdPHtz2d5WUcspuqI3pgs71cpNxh4rZflvhTQJTXr0tv7YSSI kJ37+TNV4es9jv4aTx1pURkvN9wlkGDlhjbdutGutFXf3AfkP2DPpwxBu5WsqslB 5IJ+uIYbzD+DZvRWtxQAfiiL2len2USppCxaj0g7yjRyPRixmjXEFhagdX4hfJLH NPDQEFWc9zbnUdX8dXES0E+U0v9/MdNQe1QNYUiJXNl7u3dQ/Idb2F/TXIYxx7yL pb3vKPRuOoS7HS54qcBy4A7VWyR2nGwMmvVgdLJE7Cw9gkYKoZbi6ka5NPSW05WN 03kXzrSxIMoLvDsCjchDX4NrIBxEX/giuFtbyyQd+0D9tujKiJCfx6Igj6O0YbuD WrN8qW3PiEt/ewAnJ9zZj6jSYmiLxBjEHGqEGVHfAkNAWY/pi0UoK9wNja8/zzJG yPpVryZtIkP80o7EPJROGW8rg5wdhvHUBMQjVshACkuKvfI2Fm1l/r7HwcpQY4JW lAG7u7NJ9y8t4BAjtV22f07rPaGOgYeMv8EtFxWZIbFIur3tsI6xxIO1QD8lMX1r dTbLIqW6GARC9k2X/0AiqCso20xJZY+iufCTDkR3tLOp/hsCXPw=
    =AIbz
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to All on Mon Nov 4 11:10:02 2024
    Dear Debian community,

    this is Bits from DPL for October. In addition to a summary of my
    recent activities, I aim to include newsworthy developments within
    Debian that might be of interest to the broader community. I believe
    this provides valuable insights and foster a sense of connection across
    our diverse projects. Also, I welcome your feedback on the format and
    focus of these Bits, as community input helps shape their value.


    Ada Lovelace Day 2024
    =====================

    As outlined in my platform, I'm committed to increasing the diversity of
    Debian developers. I hope the recent article celebrating Ada Lovelace
    Day 2024--featuring interviews with women in Debian[al1]--will serve as an inspiring motivation for more women to join our community.

    [al1] https://lists.debian.org/debian-women/2024/10/msg00000.html


    MiniDebConf Cambridge
    =====================

    This was my first time attending the MiniDebConf in Cambridge[md1],
    hosted at the ARM building. I thoroughly enjoyed the welcoming
    atmosphere of both MiniDebCamp and MiniDebConf. It was wonderful to
    reconnect with people who hadn't made it to the last two DebConfs, and,
    as always, there was plenty of hacking, insightful discussions, and
    valuable learning.

    If you missed the recent MiniDebConf, there's a great opportunity to
    attend the next one in Toulouse[md2]. It was recently decided to
    include a MiniDebCamp beforehand as well.

    [md1] https://wiki.debian.org/DebianEvents/gb/2024/MiniDebConfCambridge
    [md2] https://wiki.debian.org/DebianEvents/fr/2024/Toulouse


    FTPmaster accepts MRs for DAK
    =============================

    At the recent MiniDebConf in Cambridge, I discussed potential
    enhancements for DAK to make life easier for both FTP Team members and developers. For those interested, the document "Hacking on DAK" [dak1]
    provides guidance on setting up a local DAK instance and developing
    patches, which can be submitted as MRs.

    As a perfectly random example of such improvements some older MR, "Add
    commands to accept/reject updates from a policy queue"[dak2] might give
    you some inspiration.

    At MiniDebConf, we compiled an initial list of features that could
    benefit both the FTP Team and the developer community. While I had
    preliminary discussions with the FTP Team about these items, not all
    ideas had consensus. I aim to open a detailed, public discussion to
    gather broader feedback and reach a consensus on which features to
    prioritize.


    - Accept+Bug report

    Sometimes, packages are rejected not because of DFSG-incompatible
    licenses but due to other issues that could be resolved within an
    existing package (as discussed in my DebConf23 BoF, "Chatting with
    ftpmasters" [dak3]). During the "Meet the ftpteam" BoF [dak4], a new
    option was proposed for FTP Team members reviewing packages in NEW:

    Accept + Bug Report

    This option would allow a package to enter Debian (in unstable or
    experimental) with an automatically filed RC bug report. The RC bug
    would prevent the package from migrating to testing until the issues
    are addressed. To ensure compatibility with the BTS, which only
    accepts bug reports for existing packages, a delayed job (24 hours
    post-acceptance) would file the bug.


    - Binary name changes - for instance if done to experimental not via new

    When binary package names change, currently the package must go
    through the NEW queue, which can delay the availability of updated
    libraries. Allowing such packages to bypass the queue could expedite
    this process. A configuration option to enable this bypass
    specifically for uploads to experimental may be useful, as it avoids
    requiring additional technical review for experimental uploads.

    Previously, I believed the requirement for binary name changes to
    pass through NEW was due to a missing feature in DAK, possibly
    addressable via an MR. However, in discussions with the FTP Team, I
    learned this is a matter of team policy rather than technical
    limitation. I haven't found this policy documented, so it may be worth
    having a community discussion to clarify and reach consensus on how we
    want to handle binary name changes to get the MR sensibly designed.


    - Remove dependency tree

    When a developer requests the removal of a package--whether entirely
    or for specific architectures--RM bugs must be filed for the package
    itself as well as for each package depending on it. It would be
    beneficial if the dependency tree could be automatically resolved,
    allowing either:

    a) the DAK removal tooling to remove the entire dependency tree
    after prompting the bug report author for confirmation, or

    b) the system to auto-generate corresponding bug reports for all
    packages in the dependency tree.

    The latter option might be better suited for implementation in an MR
    for reportbug. However, given the possibility of large-scale removals
    (for example, targeting specific architectures), having appropriate
    tooling for this would be very beneficial.

    In my opinion the proposed DAK enhancements aim to support both FTP Team members and uploading developers. I'd be very pleased if these ideas
    spark constructive discussion and inspire volunteers to start working on them--possibly even preparing to join the FTP Team.


    On the topic of ftpmasters: an ongoing discussion with SPI lawyers is
    currently reviewing the non-US agreement established 22 years ago[dak5]. Ideally, this review will lead to a streamlined workflow for ftpmasters, removing certain hurdles that were originally put in place due to legal requirements, which were updated in 2021.

    [dak1] https://salsa.debian.org/ftp-team/dak/-/blob/master/docs/development.rst?ref_type=heads
    [dak2] https://salsa.debian.org/ftp-team/dak/-/merge_requests/270
    [dak3] https://debconf23.debconf.org/talks/31-chatting-with-ftpmasters/
    [dak4] https://debconf24.debconf.org/talks/154-meet-the-ftpteam/
    Log / transcription of the BoF can be found here
    https://salsa.debian.org/tille/dc24/-/blob/ftpmaster_bof_log/etherpad/txt/154-meet-the-ftpteam.txt?ref_type=heads
    for the moment until the MR gets accepted
    [dak5] https://lists.debian.org/debian-devel-announce/2002/03/msg00019.html


    Contacting teams
    ================

    My outreach efforts to Debian teams have slowed somewhat recently.
    However, I want to emphasize that anyone from a packaging team is more
    than welcome to reach out to me directly. My outreach emails aren't
    following any specific orders--just my own somewhat nave view of Debian,
    which I'm eager to make more informed.

    Recently, I received two very informative responses: one from the Qt/KDE
    Team, which thoughtfully compiled input from several team members into a
    shared document [ct1]. The other was from the Rust Team, where I
    received three quick, helpful replies--one of which included an invitation
    to their upcoming team meeting.

    [ct1] https://mensuel.framapad.org/p/4dp9h91jgh-aa34?lang=fr


    Interesting readings on our mailing lists =========================================

    I consider the following threads on our mailing list some interesting
    reading and would like to add some comments.

    Sensible languages for younger contributors -------------------------------------------

    Though the discussion on debian-devel about programming languages took
    place in September[la1], I recently caught up with it. I strongly
    believe Debian must continue evolving to stay relevant for the future.

    "Everything must change, so that everything can stay the same."
    -- Giuseppe Tomasi di Lampedusa, The Leopard

    I encourage constructive discussions on integrating programming
    languages in our toolchain that support this evolution.

    [la1] https://lists.debian.org/debian-devel/2024/09/msg00268.html


    Concerns regarding the "Open Source AI Definition" --------------------------------------------------

    A recent thread on the debian-project list discussed the "Open Source AI Definition" [ai1]. This topic will impact Debian in the future, and we
    need to reach an informed decision. I'd be glad to see more perspectives
    in the discussions--particularly on finding a sensible consensus,
    understanding how FTP Team members view their delegated role, and
    considering whether their delegation might need adjustments for clarity
    on this issue.

    [ai1] https://lists.debian.org/debian-project/2024/10/msg00005.html


    Kind regards
    Andreas.

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

    iQIzBAABCAAdFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmcom3gACgkQV4oElNHG RtFm9w/+Pvw40VfqQY1vKezy/3Il8ZR1XPLGZ+sAP08nkJT+7vrYdxr11joqzOOf mWTCGp7+0atVCShJ8GFRglmvFzOseyhH5yN05ckqUiWuTE8eiWrC8Fla7l+60S4Z e5913/WT7Au9BSWRS+w2a8FBJuBw1UBudHrWB9ozGJ2UWgWxNrijU/Mz9wm94/t0 bGQX8RKpfBTrZbKfHaOSZ6z0jZ/EeQygIulpsYkRNGxpeIV8j3nBg/rGyd1I9o2C kxEEsS1eAdh8t6BBC0/qtm9UzWGZq6SKMdr95vYcCcobcvP1kAo1WcxyeEiaID6L fGoZ4QiVUreF2rnzBtZxMzG2bkSSitTjopmNLd+flnmdvDrqbnuAmswIg2gyt2sL 8jv3JHKqFdXb/N+rRd3F54k9ehfbmczbqhgkO40WXrtpiY2AVAWDl/i3cIRcw1W4 VL7ifYzFY/+z0udjOk7lo85nis2JsjD8s5XK24RqWh/f2pqUJdoFlbmnT+MccLXd K1GMsbZmmCrxZx5utrcHWfpTbbJi3Pdszl+DdVVjF0ftg8HFcXGqyVBMI6wpXOKR /KAaRA191QGe63N042ptOt1V91jrlGkbFjLx/lB39ODFCFlMjUXTIMKCMQiu3v+c DRd+FyAc0EZe9NIFSbSaYbLv7DDaTvvI50tcuedajvYKiyBLWKo=
    =AAXT
    -----END PGP SIGNATURE-----

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

    This is bits from DPL for November.


    MiniDebConf Toulouse
    ====================

    I had the pleasure of attending the MiniDebConf in Toulouse, which
    featured a range of engaging talks[mt1], complementing those from the
    recent MiniDebConf in Cambridge. Both events were preceded by a DebCamp,
    which provided a valuable opportunity for focused work and
    collaboration.

    DebCamp
    -------

    During these events, I participated in numerous technical discussions on
    topics such as maintaining long-neglected packages, team-based
    maintenance, FTP master policies, Debusine, and strategies for
    separating maintainer script dependencies from runtime dependencies,
    among others. I was also fortunate that members of the Publicity Team
    attended the MiniDebCamp, giving us the opportunity to meet in person
    and collaborate face-to-face.

    Independent of the ongoing lengthy discussion on the Debian Devel
    mailing list[mt2], I encountered the perspective that unifying Git
    workflows might be more critical than ensuring all packages are managed
    in Git. While I'm uncertain whether these two questions--adopting Git as
    a universal development tool and agreeing on a common workflow for its
    use--can be fully separated, I believe it's worth raising this topic for further consideration.

    Attracting newcomers
    --------------------

    In my own talk[mt3], I regret not leaving enough time for questions--my apologies for this. However, I want to revisit the sole question raised,
    which essentially asked: Is the documentation for newcomers sufficient
    to attract new contributors? My immediate response was that this
    question is best directed to new contributors themselves, as they are in
    the best position to identify gaps and suggest improvements that could
    make the documentation more helpful.

    That said, I'm personally convinced that our challenges extend beyond
    just documentation. I don't get the impression that newcomers are lining
    up to join Debian only to be deterred by inadequate documentation. The
    issue might be more about fostering interest and engagement in the first
    place.

    My personal impression is that we sometimes fail to convey that Debian
    is not just a product to download for free but also a technical
    challenge that warmly invites participation. Everyone who respects our
    Code of Conduct will find that Debian is a highly diverse community,
    where joining the project offers not only opportunities for technical contributions but also meaningful social interactions that can make the
    effort and time truly rewarding.

    In several of my previous talks (you can find them on my talks
    page[mt4]--just search for "team," and don't be deterred if you see
    "Debian Med" in the title; it's simply an example), I emphasized that
    the interaction between a mentor and a mentee often plays a far more significant role than the documentation the mentee has to read. The key
    to success has always been finding a way to spark the mentee's interest
    in a specific topic that resonates with their own passions.


    Bug of the Day
    --------------

    In my presentation[mt3], I provided a brief overview of the Bug of the
    Day initiative, which was launched with the aim of demonstrating how to
    fix bugs as an entry point for learning about packaging. While the
    current level of interest from newcomers seems limited, the initiative
    has brought several additional benefits.

    I must admit that I'm learning quite a bit about Debian myself. I often
    compare it to exploring a house's cellar with a flashlight--you uncover everything from hidden marvels to things you might prefer to discard.
    I've also come across traces of incredibly diligent people who have
    invested their spare time polishing these hidden treasures (what we call
    NMUs). The janitor, a service in Salsa that automatically updates
    packages, fits perfectly into this cellar metaphor, symbolizing the
    ongoing care and maintenance that keep everything in order. I hadn't
    realized the immense amount of silent work being done behind the
    scenes--thank you all so much for your invaluable QA efforts.


    Reproducible builds
    -------------------

    It might be unfair to single out a specific talk from Toulouse, but I'd
    like to highlight the one on reproducible builds[mt5]. Beyond its
    technical focus, the talk also addressed the recent loss of Lunar, whom
    we mourn deeply[mt6]. It served as a tribute to Lunar's contributions
    and legacy. Personally, I've encountered packages maintained by Lunar
    and bugs he had filed. I believe that taking over his packages and
    addressing the bugs he reported is a meaningful way to honor his memory
    and acknowledge the value of his work.


    [mt1] https://toulouse2024.mini.debconf.org/schedule/
    [mt2] https://lists.debian.org/debian-devel/2024/11/msg00459.html
    [mt3] https://toulouse2024.mini.debconf.org/talks/10-bits-from-dpl/
    [mt4] https://people.debian.org/~tille/talks/
    [mt5] https://toulouse2024.mini.debconf.org/talks/4-reproducible-builds-rebuilding-what-is-distributed-from-ftpdebianorg/
    [mt6] https://www.debian.org/News/2024/20241119


    Advent calendar bug squashing
    =============================

    I’d like to promote an idea originally introduced by Thorsten Alteholz,
    who in 2011[ac1] proposed a Bug Squashing Advent Calendar for the Debian
    Med team. (For those unfamiliar with the concept of an Advent Calendar,
    you can find an explanation on Wikipedia[ac2].) While the original
    version included a fun graphical element—which we’ve had to set aside
    due to time constraints (volunteers, anyone?)—we’ve kept the tradition alive by tackling one bug per day from December 1st to 24th each year.
    This initiative helps clean up issues that have accumulated over the
    year.

    Regardless of whether you celebrate the concept of Advent, I warmly
    recommend this approach as a form of continuous bug-squashing party for
    every team. Not only does it contribute to the release readiness of your team’s packages, but it’s also an enjoyable and bonding activity for
    team members.


    [ac1] https://lists.debian.org/debian-med/2011/11/msg00124.html
    [ac2] https://en.wikipedia.org/wiki/Advent_calendar


    Best wishes for a cheerful and productive December

    Andreas.


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

    iQIzBAABCAAdFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmdN4RcACgkQV4oElNHG RtEzYg//er/LRFKsgovaze9bQhoCpbwdq1Rx8EryyV7H5bBBTAP794bwpnpEiqDH /Hukiy/5nd9bkdaEUQLleB0Mmb+nlS6evPpwFImvkmEvITRvCL4oY9w0urqAVE54 Bp144kotm2hPqOurzLVbxeoVvvJ5l9u5/isi0TQCy8IarhuMUaq+taCXD28hIz7L PMKiwCJCbwwxqv/WSaNtpsbW8lsJV/3s6iC0/5nZtYu/a93iLuocP/qpHF32lW5+ waOhLv28VzeBD3e9TiBCUxzstr71iRoO0iOKnf6L/wNnOhYNuXKN8ogByqlZbCt/ bqEkj/btnwa0bpKfwEGGLOqvNooYqF974r396B1hLKLZ9v5tol+ENhpAEvJQTj3F JTRzQms7P9J/GRSUCVIPvV7G+XEcdvujbkUWR/JPoyBwr8a68hx8sAs20cNDpU/i sU8e1hf+vblUyPBPcZtzOxahAUac+A90ZiYU2oeJ969pci7Q5n6U+yR1o/iRgv7x Ppi9gz4eyb/uPIqa7z2nm7AtfS+gOUkSY6V8mw/IEJuh1Qw/EpOb/kgCv8XLCfSe Ijhyoz7tct57CtO1aEkqe8GgXgZGQBho+2h2dds+yn9aOlXTmDql/OM5PmRPEyF/ zn2x9DHNIS9BQgzQUD+VGvs12S0b8IGq7EAK9XnEhhAzy0FP0g4=
    =Jwym
    -----END PGP SIGNATURE-----

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

    this is bits from DPL for December.

    Happy New Year 2025! Wishing everyone health, productivity, and a
    successful Debian release later in this year.

    Strict ownership of packages
    ============================

    I’m glad my last bits sparked discussions about barriers between
    packages and contributors, summarized temporarily in some post on the debian-devel list[op1]. As one participant aptly put it, we need a way
    to visibly say, "I’ll do the job until someone else steps up."[op2]
    Based on my experience with the Bug of the Day initiative, simplifying
    the process for engaging with packages would significantly help.

    Currently we have

    1. NMU[op3]
    The Developers Reference outlines several preconditions for NMUs,
    explicitly stating, "Fixing cosmetic issues or changing the
    packaging style in NMUs is discouraged." This makes NMUs unsuitable
    for addressing package smells [op4]. However, I’ve seen NMUs used
    for tasks like switching to source format 3.0 or bumping the
    debhelper compat level. While it’s technically possible to file a
    bug and then address it in an NMU, the process inherently limits
    the NMUer’s flexibility to reduce package smells.

    2. Package Salvaging[op5]
    This is another approach for working on someone else’s packages,
    aligning with the process we often follow in the Bug of the Day
    initiative. The criteria for selecting packages [ot6] typically
    indicate that the maintainer either lacks time to address open
    bugs, has lost interest, or is generally MIA.

    Both options have drawbacks, so I’d welcome continued discussion on
    criteria for lowering the barriers to moving packages to Salsa and
    modernizing their packaging. These steps could enhance Debian overall
    and are generally welcomed by active maintainers. The discussion also highlighted [op7] that packages on Salsa are often maintained
    collaboratively, fostering the team-oriented atmosphere already
    established in several Debian teams [op8].


    [op1] https://lists.debian.org/debian-devel/2024/12/msg00480.html
    [op2] https://lists.debian.org/debian-devel/2024/12/msg00502.html
    [op3] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu [op4] https://trends.debian.net/packages-with-smells-sorted-by-maintainer.txt [op5] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
    [op6] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks#bug-of-the-day
    [op7] https://lists.debian.org/debian-devel/2024/12/msg00479.html
    [op8] https://lists.debian.org/debian-devel/2024/12/msg00474.html


    Salsa
    =====

    Continuous Integration
    ----------------------

    As part of the ongoing discussion about package maintenance, I’m
    considering the suggestion to switch from the current opt-in model for
    Salsa CI to an opt-out approach [sc1]. While I fully agree that human verification is necessary when the pipeline is activated [sc2], I
    believe the current option to enable CI is less visible than it should
    be. I’d welcome a more straightforward approach to improve access to
    better testing for what we push to Salsa.

    [sc1] https://lists.debian.org/debian-devel/2024/12/msg00583.html
    [sc2] https://lists.debian.org/debian-devel/2024/12/msg00601.html


    Number of packages not on Salsa
    -------------------------------

    In my campaign, I stated [os1] that I aimed to reduce the number of
    packages maintained outside Salsa to below 2,000. As of March 28, 2024,
    the count was 2,368. As of this writing, the count stands at 1,928
    [os2], so I consider this promise fulfilled. My thanks go out to
    everyone who contributed to this effort. Moving forward, I’d like to set
    a more ambitious goal for the remainder of my term and hope we can
    reduce the number to below 1,800.

    [os1] https://lists.debian.org/debian-vote/2024/03/msg00057.html
    [os2] UDD query:
    SELECT DISTINCT count(*) FROM sources WHERE release = 'sid' and vcs_url not like '%salsa%' ;



    Past and future events
    ======================

    Talk at MRI Together
    --------------------

    In early December, I gave a short online talk [mt1], primarily focusing
    on my work with the Debian Med team. I also used my position as DPL to
    advocate for attracting more users and developers from the scientific
    research community.

    [mt1] https://people.debian.org/~tille/talks/20241205_mri_together_24/debian-science_mri_together_24_handout.pdf


    FOSSASIA
    --------

    I originally planned to attend FOSDEM this year. However, given the
    strong Debian presence there and the need for better representation at
    the FOSSASIA Summit [fa1], I decided to prioritize the latter. This
    aligns with my goal of improving geographic diversity. I also look
    forward to opportunities for inter-distribution discussions.

    [fa1] https://eventyay.com/e/4c0e0c27


    Debian team sprints
    -------------------

    Debian Ruby Sprint

    I approved the budget for the Debian Ruby Sprint, scheduled for January
    2025 in Paris [sp1]. If you’re interested in contributing to the Ruby
    team, whether in person or online, consider reaching out to them. I’m
    sure any helping hand would be appreciated.


    Debian Med sprint

    There will also be a Debian Med sprint in Berlin in mid-February [sp2].
    As usual, you don’t need to be an expert in biology or medicine—basic
    bug squashing skills are enough to contribute and enjoy the friendly
    atmosphere the Debian Med team fosters at their sprints. For those
    working in biology and medicine, we typically offer packaging support.
    Anyone interested in spending a weekend focused on impactful scientific
    work with Debian is warmly invited.

    [sp1] https://wiki.debian.org/Teams/Ruby/Meeting/Paris2025
    [sp2] https://wiki.debian.org/Sprints/2025/DebianMed


    Again all the best for 2025

    Andreas.


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

    iQIzBAABCAAdFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmd5TDoACgkQV4oElNHG RtGo6hAAgpti6dlHLfci43WfixIDnHCzklv3eYTLoea0zUK4RTyHVQxRRCLa71tJ 9fuY8xf15N6b8fL6wF8K6abyljB/3m7Wc3p3N15G1dVa369lFUBXWRb3lid23LiS RMB2wtH2f/UEQqTG27o/SKOvaioauiqHdJ/lomNC1PPhAPbfFzPTQ73ZFY2s4B1S uciioWM4qN1d/t0LUIweYJZM97DdaOu7Lviqs7ZT26cMokYEWVzosFu0pEbQqmpN Zd+6CV7SYZ+XIwwyVTHBqY9aLVXMR7zG5GKn/cqcZewXzGd5lEx6uWd/DmCUx1Jz 7kWlFnA09TZ+s0gEsDqq670FtrAJy/wuj38uVLvdxl2JmFUhWIS1uY/vOCDyCRzg C0QleB9L2JVjZSvl/8CrHkb6ELBHL0+SXPlH64uP8s/4cSqIkNuTq19Z5YPxofGY 9TM45S5SjjB6i67BLt7GfXIzhAcqS8PQ1QHgNZY8Vklnuk+A10/buHtR+wku2yob OLEcrYQOn9mXbP/MVqVslsjEkmq1pm704mZ63mA4zUFWhq7pXjX9s921I83VB4wd 1WvhaWC67oyjkdb01g+vieUMAHs0Z5KQ41SICJKyS2Ay05edT9m6fLjSl2DKun0Y 4kSB4f8pyr2d4Gid7QT1GFIJtF02NRN3XpbUcjOS7pP9wntArn8=
    =yf0P
    -----END PGP SIGNATURE-----

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