Bug#727708: loose ends for init system decision
On Mon, Dec 30, 2013 at 10:24 PM, Steve Langasek wrote:
> On Mon, Dec 30, 2013 at 08:12:19PM -0500, Michael Gilbert wrote:
>> > 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.
>
> I don't agree with that conclusion.
That no unhappiness will arise out of this decision is, I think, a
quite unlikely outcome, so this statement is quite surprising. As
Russ eloquently states today [1]
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.
The TC needs to find a path that minimizes unintended social
consequences. I have been trying to make the case in this thread that
the only reasonable solution that does so is one which empowers all
camps to do work to further their cause without feeling excluded.
Eventually, and this may take sometime but everything worth doing
does, a clearly superior solution will emerge that can, when ready,
become the default.
> When it comes to technology choices, you win some and you lose some.
The fact that there may be winners and losers is not the issue at
hand. It is the specter of being disqualified before the game even
starts.
> Your proposal smells like the status quo.
That is only true if none of the systemd, openrc, and upstart teams
get to the point where their init is usable, then we're stuck with
sysvinit. This is probably an unlikely circumstance, but sysvinit
does work.
> Namely, instead of the project
> making a decision and being able to all pull together in the same direction
> to provide the best possible OS, we will continue to coast, squandering
> efforts on preserving users' ability to make choices about things that no
> user should ever be asked to care about
The project never goes in the same direction. 1,000 people go in
their own direction, creative solutions eventually emerge, one often
gains the most traction, but others remain as alternatives (think
debhelper/cdbs/etc), and choice and freedom remain. It will be a
major change in project governance to select any resolution prior to
emergence.
In my opinion, the only reasonable TC decision is one that requests
project members feel empowered to work toward the solutions that they
are interested in, while being open-minded and non-obstructive to all
of the other competing solutions.
Best wishes,
Mike
Reply to: