Re: GR: Selecting the default init system for Debian
[ Given the tone in this mail, I'd usually not bother replying, but I
guess it's my duty given the proposed changes to the draft. ]
Hi,
On Sun, 2014-01-19 at 16:53:12 +0100, Holger Levsen wrote:
> I think you are missing the following options and have only listed options
> which you consider sensible or which you loath:
I'd have guessed it'd be obvious why I might not include options I
consider inappropriate or insane? People can always propose amendments
for those. Of course, that does not mean I might have missed other good
options people might favour.
> h.) support them all equally: systemd, upstart, sysv and openrc and keep sysv
> as the default
> i.) support them all equally: systemd, upstart, sysv and openrc and make $foo1
> the default
> j) support them all equally: systemd, upstart, sysv and openrc and make $foo2
> the default
> k.) support them all equally: systemd, upstart, sysv and openrc and make $foo3
> the default
I'd actually love if the project could support all init systems
equally, and not even these, all the ones that have not been proposed
like runit, minit, etc. I'm actually an idealist, but in a voluntary
project like Debian, there's a point where ones ideals must not take
precedence, when confronted with ideas that might imply making others
to do things they don't want which I find totally inappropriate; this
is a maxim I've tried to follow when drafting the GR. For example I
think it would be totally uncalled for, to force the systemd maintainers
to carry portability patches (if those ever happen) when their upstream
and themselves have stated that would make them very unhappy, when
other people could instead fork systemd or reimplement their
interfaces (and this is talking as a porter).
Unfortunately I think supporting all these equally is very much
unfeasible, and would put a huge burden on maintainers. One thing is
for a maintainer preferring init system X, while the default is Y,
to support both natively, the other is requiring them to test and run
all these different init systems on each upload, either through VMs,
dedicated hosts, or init system package switches. We do not require of
maintainers that they support themselves all our architectures, and we
don't even consider it a serious bug if a package has never been built
for one (be it Linux-based or not, mind you), the same should apply to
init systems IMO. So in these cases I consider they are already
covered in spirit by the non-exclusive options in the draft.
> l.) accept the TC decision, whatever that will be
> m.) wait for the TC decision and then revote on this GR
> n.) wait for the TC decision and then start a new GR on this topic
See my reply to Enrico.
> And, frankly, I'm disappointed by your *lousy* research on the topic (see both
> Tollefs and Steves reply), while at the same time I think you have given an
> *excellent* (bad) example, why voting is or can be bad: uninformed people vote
> on matters they dont fully understand.
>
> Given your lousy research I do assume you havent read the tech-ctte bug in
> question. If you had, I'm don't think you would think the same about the
> topic. (But then, most peoples minds aren't or cannot be changed by new
> information.)
> I do think this bug contains among of the best research of this topic. If you
> as a GR proposer cannot be bothered to inform yourself in the best possible
> way about it, I fear for a rather totally uninformed decision of other voters.
> cheers,
> Holger, who has come to the conclusion that this init system discussion is
> way more a bikeshed than what I would have assumed half a year ago.
> Indeed 99% of our users don't care and the majority of those who do
> care want their bikeshed their way or the highway...
I'm actually flabbergasted at how you've reached that conclusion,
given that I've tried very hard to not imprint any judgment on any
given init sytem, on purpose, so to avoid having the GR proposal
itself turn into a monster rehash of the same.
Personally, I do actually trust my fellow project members to get
properly informed themselves by the time of a vote, seeking
help/advice/inspiration from others, not voting if they don't care
at all what the project decides, etc.
On one hand I don't think I should be dignifying this with a reply, on
the other not clarifying might possibly cloud the impression or lack
thereof of due process when drafting the GR itself.
I'd also rather not be talking about my credentials, or lack thereof,
TBH, I'd have happily replied in private if asked nicely. I'd rather
talk just about the merits or lack thereof of the options in the GR
draft itself. In any case, given the character assassination above,
here's my involvement in this issue, trying to keep any possible
judgment for any particular init system out of it, because my
preference, really, would be for the project at large to reach
consensus on the issue:
* While at Nokia, was involved in the evaluation and decision of the
default init system for Maemo (circa 2006), checking available init
systems at the time.
* Wrote and maintained maemo-launcher, a process supervising daemon.
* Maintain the xfstt daemon as upstream.
* Maintain start-stop-daemon as part of dpkg.
* Have followed the blog posts related to upstart by Scott, James and
Steve and the ones related to systemd from Lennart.
* Have followed the various articles and initial "comment discussions"
in LWN, lately stopped with the latter as they seem like a waste of
time to me.
* Have watched several presentations online for both upstart an systemd.
* Have had git clones (yes) for upstart and systemd for a very long
time, openrc since first announced on debian-devel.
* Have skimmed over the above codebases and subsequent commits,
including sysvinit's for which I've also done portability fixes.
* Have evaluated, OOC, the portability issues of upstart and systemd,
from lists posted by Scott and Lennart, and from going over the code,
updating <http://www.hadrons.org/~guillem/debian/ports/porting> with
my findings in the process.
* Started poking at porting libnih and upstart to GNU/kFreeBSD for fun,
to see how difficult it would be, but got dragged by more important
things. Should probably unearth and finish the patches eventually, as
they where intended to use kqueue natively instead of the compat
solution Dimitri has chosen.
* Have read all monster threads in debian-devel, although I've to say
that was with few exceptions, an overall and massive waste of time.
* Have followed the FESCo meeting minutes ruling on their init system.
* Have followed the discussion in the tech-ctte.
* Probably others I've since forgotten…
Guillem
Reply to: