Bug#727708: loose ends for init system decision
On Mon, Dec 30, 2013 at 7:20 PM, Russ Allbery wrote:
> 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.)
The key differences are that it is more succinct, roles and
requirements are defined, no init system is outright rejected, and the
default is selected on demonstrable merit.
> 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.
Unfortunately at least two camps will be entirely dejected by any TC
mandate here.
> 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.
I don
> 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.
And Debian ends up with not only apple pie, but pumpkin and blueberry
pies, and of in a corner there will be others thinking about
cinnamon-spiced apple and blueberry-raspberry and other
never-before-seen flavors. What a wonderful bake-off that would be
:)
Think about how it would go over if the directors of that metaphorical
bake-off forced all the participants to produce the exact same pie.
No one would really want to participate, and winning would be entirely
meaningless. It wouldn't be a bake-off at all. It would be more like
a mass-production assembly line.
Best wishes,
Mike
Reply to: