• Bits from the DPL (August 2019)

    From Sam Hartman@21:1/5 to All on Wed Sep 18 22:50:01 2019
    Dear Debian:

    First, we're approaching the deadline for projects and mentors for the
    next round of Outreachy [15]. If you have a corner of Debian and would
    bi interested in helping show a new intern why what you're working on is
    really exciting, then please take a look at that announcement.
    You don't have a lot of time, so please act quickly.

    I like to start out my Bits from the DPL with a quick glimpse into some
    corner of Debian.
    This month comes with mixed emotions as I take a moment to thank several
    people who have stepped back from their roles. No, nothing is going
    wrong; this is just the normal consequences of people taking stock of
    their involvement after the Buster release.

    Just before August started, Laura Arjona Reina retired from being
    involved in DebConf organization [16]. Since then, two members of the
    DebConf committee have resigned: Jonathan Carter [17] and Lucas Nussbaum
    [18].

    Steve McIntyre [19] and Luca Filipozzi stepped down from the cloud team.

    One of the best things about Debian is that especially in the last few
    years we've developed a culture of taking stock of our own involvement
    and asking ourselves whether we still want to be in some position. All
    of the above are still actively involved in Debian. In all cases they
    have just realized that it is time to move on from a particular role and
    focus on the parts of Debian that they choose.

    Rotation of people helps our organization stay strong.
    So I'd like to thank you all for your service in these roles, and thank
    you for making room for others to get involved.

    And at least for the DebConf committee and Cloud Team, I need to work
    with the community and teams to find replacements:-)

    [15]: https://lists.debian.org/msgid-search/CAPdE3R8N=1wGn3H1ksNsbXRa0d7puNhcizkieNZ38KMMYqA+Cg@mail.gmail.com
    [16]: https://lists.debian.org/msgid-search/e56ed309-796c-cb5f-4e12-7f4184fe1904@debian.org
    [17]:
    https://lists.debian.org/9ee3ae83-60d5-ab53-6a52-416cee3d99ea@debian.org
    [18]: https://lists.debian.org/20190917135320.GA29926@xanadu.blop.info
    [19]: https://lists.debian.org/20190804152748.GM25268@tack.einval.com

    Init System Diversity
    =====================

    I've spent a lot of time over the last month looking at init system
    issues. On July 16, a member of the release team blocked the transition
    of elogind into testing. The only explanation given was one line in a
    hint saying it was broken and a discussion on IRC. On August 7 (a month later), the elogind maintainer [1] described his understanding of the
    concerns. He received no substantive reply until September 3 [2].

    As of September 11, the situation has been more regularized. There is
    an RC bug [3] documenting the concerns.

    I can see why there are concerns about the elogind in unstable. Elogind attempts to provide an implementation of services needed by common
    desktops from systemd-logind that does not depend on systemd. To do
    that it provides an alternate implementation of the libraries in
    lybsystemd0 that conflict/replace both libsystemd0 and systemd. So your program links against libsystemd, but at run time, you actually get a
    hopefully compatible library from elogind instead. Unless we're willing
    to patch every program that depends on systemd functionality to support
    both systemd and elogind explicitly, we need to do something like this.
    As I understand systemd-shim had a different integration point: it
    integrated at the dbus layer rather than the library layer. Elogind has
    the advantage that its code is based more directly on systemd and it has
    been easier to keep it in sync. Even though maintaining multiple implementations of an interface involves some challenge, there are a
    number of Linux distributions successfully using Elogind.

    Additional complexity comes in because the elogind in unstable tries to
    use apt dependencies/conflicts/replaces/provides to switch out the
    elogind library for the systemd libraries. This approach has been
    refined over time: I think this is the third or fourth iteration of the approach [4]. The systemd maintainers have been canvased for comments
    on the approach and gave tacit approval. And yet some fairly simple
    test cases leave a broken system with a non-working apt and no elogind
    [5]. That is apparently an apt bug [6]. Even after that bug is fixed,
    there is no way to migrate from systemd to elogind without removing any
    desktop environment that is installed. And none of this deals with the original release team member concern [3].

    So, this is a technical problem. It sounds like a hard technical
    problem, but why is this DPL business?

    I think to move forward, the elogind maintainers, systemd maintainers
    and release team need to work together. They may need to get input from
    the apt and possibly dpkg maintainers. The communication is not
    working.

    On one side, there is frustration, accusation and abuse of the BTS
    (trying to override a maintainer's decisions about bug severity and
    which bugs will be fixed). On the other side, there are long silences, inadequate documentation of concerns, and a failure to engage. In one
    case I reached out to one of the systemd maintainers trying to mediate a discussion. He indicated unwillingness to engage and emotional
    exhaustion. I asked for a clarification of why this was hard to engage
    with. I got a polite note saying that the problem wasn't me, but
    implying that even answering the question of why engaging was hard was
    going to take long enough that I shouldn't expect an answer any time
    soon. Since then I've gotten silence. There has been one really
    positive element in at least my interactions: Mark Hindley has been
    working hard to help me understand the issue and has displayed amazing restraint and compassion in trying to solve these problems.

    This is a DPL problem because we can't get the right people together to
    make progress. It's not an easy problem. Developers don't have to do
    any work: if the systemd maintainers are emotionally exhausted and don't
    want to deal with this, they don't have to. (Although if the project is committed to init diversity, they cannot stand in the way.)

    And yet the systemd maintainers and to a lesser extent release team face conduct that is frankly unacceptable. And in some cases that conduct is
    the frustrated reaction to years of interactions complex enough that
    we'll never untangle them. No matter how unfortunate the conduct is,
    the frustrations, anger and hurt are real.

    I want to stress that I can understand both sides here. If I were
    maintaining systemd I know I'd be absolutely done dealing with some
    people who have been involved in this discussion. If I were trying to
    get an alternate init system to continue to work, I'd be really
    frustrated. I'm not in either of those roles, and I do not fully
    understand either side's needs or feelings, but I can understand how we
    got here as a project.

    Honestly, I'm not entirely sure how to move forward. Perhaps it's just
    that I haven't talked to someone I need to. Perhaps someone will read
    this, and let me know that if I'd included them, we could get the right
    skills and authority engaged. I'll feel embarrassed and we'll all move
    on if that's the case. But I think we may be approaching a point where
    we need to poll the project--to have a GR and ask ourselves how
    committed we are to the different parts of this init diversity
    discussion. Reaffirming our support for sysvinit and elogind would be
    one of the options in any such GR. If that option passed, we'd expect
    all the maintainers involved to work together or to appoint and empower
    people who could work on this issue. It would be fine for maintainers
    not to be involved so long as they did not block progress. And of
    course we would hold the discussions to the highest standards of
    respect.

    Things may have changed since our last GR on the issue. There are 1033 non-overridden instances of lintian detecting a service unit without an
    init.d script [7]. The false positive rate seems high especially for
    packages that break their systemd integration. There's been discussion
    on debian-devel about moving to using service units as the default
    rather than init scripts [8].

    So perhaps sysvinit and init scripts have had their chance and it is
    time to move on. We could move away from init scripts as the default representation. We could stop caring about sysvinit (which isn't quite
    the same thing but is related). That would leave non-linux ports in an unfortunate position. But right now there are no non-linux ports in the
    main archive. So perhaps we don't even care about that. Again, a
    change, but a change that we can ask ourselves if we are ready to make.

    None of that answers the question of Elogind. In some ways dropping
    Elogind is a bigger decision. If we ever want to try something
    different than Systemd, we'll need something like Elogind. Even many
    people who believe systemd is a step forward have concerns about it. Do
    we really want all of the things systemd does in one place? We've seen
    a lot of advantages, but are we sure we don't want to experiment with alternatives. For large classes of experimentation, Elogind or
    something like it will be essential. It seems like adding elogind later
    after it has been removed will be harder than keeping it working. I'm concerned that removing Elogind commits us to Systemd-based solutions
    with a very high cost to try new things or change direction. For me
    that's a step we should be very careful before taking.

    I don't know what the answers are. I do know we need to respect our contributors. In my mind that means either working with the elogind
    proponents or politely telling them we're no longer interested. It does
    not mean as some have suggested hoping that sysvinit will just die over
    time. I think it may be time for the project to focus on this issue
    again.

    [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934132
    [2]:
    https://lists.debian.org/20190903193451.ugrxef53kjxut6t2@topinambour.cristau.org
    [3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940034
    [4]: https://bugs.debian.org/923244
    [5]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934491
    [6]: https://bugs.debian.org/935910
    [7]:
    https://lintian.debian.org/tags/package-supports-alternative-init-but-no-init.d-script.html
    [8]: https://lists.debian.org/msgid-search/87h86qvh1q.fsf@proton.d.airelinux.org

    Git Packaging
    =============

    August and Early September saw lots of progress on the ongoing Git
    packaging discussion. I started a number of consensus threads. I asked
    about what I hoped were relatively easy assumptions [9] (they were
    [10]). I asked some questions about the use of native packages [11].
    Then I started a long-ranging discussion about when to use Salsa and how
    to use Salsa[12].

    The discussion generated enough mail that I have not yet found time to
    issue a consensus call. Here are some of the results I'm fairly sure
    of:

    * You cannot ignore the BTS in favor of merge requests [10].

    * Most work is likely to continue to happen in teams. Many teams host
    their packages on Salsa. That's great.

    * I think I'm close to making a consensus call that when you don't have
    another preference for individual work, you should do it in the debian
    group on Salsa. This is an area where additional comments from people
    who have read at least a good chunk of the existing discussion would
    be welcome. Enough has been discussed so far that comments from
    people who don't read a significant chunk of what we have covered
    already probably aren't going to help much.

    * We discussed using native packages when an upstream uses Git and for
    example doesn't have a great source of upstream tarballs. There are a
    lot of issues to consider that were brought up in the discussion.
    However it seems like project consensus has changed and if you
    consider these issues and still believe that's the best workflow, you
    can do so.

    * We don't recommend use of non-free services like Github, but we do not
    forbid them. I wrote a blog post about this [13] discussing use of
    non-free components in making Debian.

    I expect to start discussions on maintainer branch format and upstream
    tarballs in early October.

    [9]:
    https://lists.debian.org/msgid-search/tslh86j7hgt.fsf@suchdamage.org
    [10]:
    https://lists.debian.org/msgid-search/tsl7e70q8ks.fsf@suchdamage.org
    [11]:
    https://lists.debian.org/msgid-search/tslo909kqlx.fsf@suchdamage.org
    [13]: https://hartmans.livejournal.com/99077.html

    Upcoming Talks
    ==============

    I'll be giving a talk Sunday, September 29 at the 50th anniversary
    celebration of MIT's Student Information Processing Board [14]. SIPB
    holds a special place for me. SIPB is where I was introduced to the
    Debian community and to other Debian developers. It's where I really
    came into my own as a security and systems engineer. I'll be talking
    about how some of the small decisions we make can help to build up the
    people around us and make our free software communities strong.

    [14]: https://sipb50.mit.edu/

    Feedback
    ==========

    As always, feedback is welcome. Please don't hesitate to reach out to leader@debian.org.


    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

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

    iQEzBAEBCAAdFiEE9Li3nMNy++OFgPTCQe7SUh/WssoFAl2Cl5YACgkQQe7SUh/W ssrKsAgAxltDaE1eZdkXojy5RC5zxlrjd4FGQ59vG6PZs3EpPhFTzIiESRVirKMm +o8voRJPEjfJt/MPKu+8VyNHyqfR+IonSnjz/dmv+xFeEge+9em4ZaEER5Dhj5I2 z8FyBpMggJHWm78Dmgubl10A7iBH6Xil7wrjS2gVs6QXTq+4bGyZVQIYsXC5230+ BPyiUvOQGkAVEYv+i8r+buDNGD15FcQNMBKgi17ZZ5p0rnAikeTcIIflbFHgHt9d /rA0J3g02814UChx2KIaYzySQiWWNLqjSixXJYemu/ZrqIxnkN325SlsvEwZpJuY WYIWj1Fq7DniU9kuh+b5Sbq7Hw9A+Q==1rNJ
    -----END PGP SIGNATURE-----

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