Bug#727708: loose ends for init system decision
Michael Gilbert <mgilbert@debian.org> writes:
> On Mon, Dec 30, 2013 at 5:51 PM, Russ Allbery wrote:
>> I believe that we have enough information to make an informed choice
>> already, and that the sides are fairly well-defined and hardened in
>> their opinions. That means that this dispute falls under section 6.1.2
>> of the constitution:
> I entirely concur that the social problem resides rightly within the
> jurisdiction of the TC. With that said, however, it is worth
> considering whether the role of the TC may be more effective if directed
> at the root (the social), rather than the branches (the technical
> choice), of the problem. The key, I think, is for the TC to provide a
> reasonable path for those currently identifying with any of the hardened
> camps to redirect their negative energy away from argument and toward
> something more positive: technical work and actual code.
Well, I think it's worth pointing out that my transition plan looks
somewhat similar to your plan, as far as the jessie release. (Then it
starts diverging.) Part of my goal in writing up that plan was, as you
say, to try to provide a means for people who are committed to one system
or the other to continue to work on what they're passionate about even if
it's not chosen as the default init system.
Whether they do so or not is up to them, of course, as it should be.
However, I don't want to understate the amount of effort required to
integrate with the init system across the distribution. I'm less
pessimistic than Steve, but he's not wrong that the choice of a default
init system will have sweeping consequences for what will work and what
won't. This will particularly be the case if that init system supports
capabilities beyond the sysvinit set.
I do think it would be possible to maintain package compatibility with
both systemd and upstart. That was something I was curious about and
therefore explicitly tested as part of my evaluation, and was able to do
so to my satisfaction. That said, I tackled a fairly simple daemon, and
something like NFS support would require people with deep knowledge of
each supported init system to maintain that support.
I don't think it's a good idea to ask everyone to pursue all paths in
parallel. I think Debian does a bit too much of that right now. We
should pick a winner that we believe is technically superior and focus the
mandatory, archive-wide effort on it. We should then *not get in the way*
of people who also want to pursue alternative paths, but not assume that
they will necessarily be successful, and not require that everyone get
involved in that effort beyond the level of integrating patches that we
currently expect for, say, the Hurd port.
But, anyway, I don't think our positions are really that different. The
main difference is that I think we should pick a default init system for
jessie now, and you feel like we should do effectively an archive-wide
bake-off and then go with whatever one achieves the best integration. I
have to admit to a deep personal dislike of "contests" like that, since I
find them stressful and demotivating and think they make the process of
free software development less fun. I'd rather decide on our default and
on the mandatory work now, so that everyone knows where they stand, and
then let people make their own decisions about what they want to spend
time on beyond the required minimum.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: