Bug#727708: init system other points, and conclusion
Josselin Mouette <joss@debian.org> writes:
> Which brings me to the other point: you are not going to decide what
> people want to spend their time on. If systemd is selected as the
> default, the systemd maintainers are not going to ask Steve to fix their
> upgrades problem for them. And if upstart is selected, you will
> certainly not ask members of the systemd community - from which Debian
> would have just excluded itself - to fix Debian’s problems with not
> having systemd.
I want to second this, because I agree with it completely. It is a core
principle of Debian, featuring prominantly in the constitution:
Nothing in this constitution imposes an obligation on anyone to do
work for the Project. A person who does not want to do a task which
has been delegated or assigned to them does not need to do
it. However, they must not actively work against these rules and
decisions properly made under them.
I'm pretty sure that there are project resources available to integrate
with systemd and that there are resources available to integrate with
upstart (and there may be resources to integrate with both, although I
really don't know). But those resources are probably going to be
different in at least some cases. People are not, generally speaking,
going to spend significant amount of time and effort working on source
bases they don't like or in pursuit of goals that they don't agree with.
This is one of the points I made in my writeup about the ecosystem. These
are exactly the sort of resources that we will have to muster and maintain
going forward in order to adopt usptart. Those resources may or may not
be available in Debian today. I think that depends on how much surgery
this will require to systemd and GNOME, and possibly later to KDE and to
other packages, and what the ongoing maintenance burden will look like.
Obviously, we can share work with Ubuntu in some of these areas, which
reduces the demand for Debian-specific resources. But we certainly should
not assume that either the current GNOME maintainers or the current
systemd maintainers will be those resources. They may be, or they may
decide to go work on something else; either way, it's entirely up to them,
as it should be.
We currently have multiple dedicated groups already in place in Debian who
have clearly said they will do the work to integrate their components with
systemd, and who have either not expressed an opinion or who have
indicated they're not interested in integrating with upstart. And, I will
also point out, we have other dedicated groups in Debian who are very
concerned about the impact the adoption of systemd would have on *their*
work and *their* projects.
The degree to which this all should affect our decision-making process is
limited. That's particularly true in this case, which is one of those
decisions where, whatever we choose, some group of people in Debian who
have put a ton of work into something they care about are going to be at
least somewhat unhappy. That may be the systemd maintainers, the GNOME
team, the Hurd porters, the kFreeBSD porters, the upstart maintainers,
those who care deeply about tight Debian and Ubuntu integration, or any
number of other groups. It will probably be several of those.
Occasionally, there are decisions with sweeping consequences, and we have
to have a method for making them. The TC is that method, which can then
be overridden by General Resolution if warranted.
However, it does affect how we should talk about these decisions, and it
does affect the reality check on which approach has the most cost and on
what resources are available.
The TC doesn't get to order people to do work. We are not managers, and
Debian is not a corporation. At most we can authorize NMUs or otherwise
work around people who are preventing *other* people from doing work.
And, as such, I really dislike seeing people make statements about what
other specific people should be required to do in Debian. Making
statements about what work one believes needs to be done is a different
matter, but one should not assume that this work is going to be done by
the people currently maintaining the relevant packages if they don't agree
with it. Or if, for that matter, they get busy, they get sick, they have
children, they retire, or they decide not to do that work for any other
reason.
For example, one possible outcome here is that whatever group cares about
doing the upstart integration introduces a new systemd source package
that's split and modified in such a way so as to work with upstart as the
init system, and which conflicts with systemd as it is currently packaged.
Furthermore, the TC is also not a code review body for Debian, nor is it
our role to impose our personal asthetic or design views on the project.
If any of us in the Debian project wanted to work on something with a
dictated, top-down design, there are numerous other projects we could be
working on, including several that offer wages for such effort. One of
the core qualities of Debian is that we only dictate standards to people
when they're necessary for integration, security, or to reduce impact on
other core teams such as ftp-master, release, or security. Otherwise, we
try to let people go about their work in the way that suits them best.
This has various significant drawbacks, but the huge advantage that it
makes working on Debian fun rather than a job.
We have to make a decision here because Debian can only have one *default*
init system, and all of our packages need to work with it. Maybe that
decision necessarily involves some amount of central control over how
integrations are done, including switching maintainers or introducing new
packages in order to implement those integrations. But that's an
unfortunate consequence of necessity, not an exciting opportunity to make
everyone do everything the Right Way in an area where there are profound
disagreements.
I'm quite sure I'm not the only one who is regularly dictated design
decisions in my regular job and has no interest in being subjected to the
same thing in my hobby.
Some amount of it is necessary in order to accomplish our shared goals of
producing an integrated distribution. And some of it falls under
reasonable accomodation; for example, I believe the solution that we
arrived at with Network Manager was reasonable accomodation to the desires
of other people in Debian, and continue to defend it. But on *exactly the
same grounds*, I will defend introduction of shared library dependencies
to daemons for integration with systemd.
And we need to be very careful about what the boundaries of reasonable
accomodation are. Major surgery to one's packages contrary to fundamental
design goals that one has pursued in creating those packages is not
reasonable accomodation, and it's something we should only pursue if the
greater goal truly both warrants it and requires it, and with the full
understanding that this will often mean that the current maintainers will
step down and someone else will need to do the actual work.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: