[ 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 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140120170609.ga19...@gaara.hadrons.org
