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

Bug#727708: init system other points, and conclusion

First of all, thanks a lot for writing this mail.  It expresses a lot of
my thoughts and feelings on the subject a lot more eloquently than I am
able to do myself.  You're a wordsmith and a master of words.  I am

]] Russ Allbery 

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

Given how the voting ratio so far looks, I've been giving the whole GR
process a bit of thought lately and at least I am unlikely to pursue it,
simply because I don't think it's a good way to spend my and the
project's energy.  If you decide that you want to go with upstart,
that's obviously not what I want, but I'll rather take the consequences
of that than go one more round and appeal to the developer body at
large.  As our common astronomy geek friend puts it, I don't have the
people beans to spend on that.  Somebody else might.

Personally, I wish the TC was a bit more careful with the «people» angle
of their rulings.  You spent a lot of goodwill in the GNOME camp when
pushing through the latest NM Depends->Recommends change, and I think
it'd be a shame if we ended up losing or demotivating a good bunch of
good developers again.

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

I think what you're saying here is really important.  What Ian is asking
about is for the systemd maintainers to do a lot of work we don't want
to do, and if we end up with a resolution that basically tells the
systemd maintainers to support a chopped-up package, it'd be massively
demotivating for me personally.  From the message from Joss, it seems
like the GNOME people feel the same way.


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

The way things are going, I don't think that'd be a terrible situation,

Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Reply to: