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.
Attachment:
signature.asc
Description: PGP signature