[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bits from the DPL (August 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

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
  [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

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

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

  [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934132
  [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
  [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

* 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.

  [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/


As always, feedback is welcome.  Please don't hesitate to reach out to

Attachment: signature.asc
Description: PGP signature

Reply to: