Hi Steve! On Sat, 2014-01-18 at 19:16:44 -0800, Steve Langasek wrote: > On Sun, Jan 19, 2014 at 01:01:44AM +0100, Guillem Jover wrote: > > Moreover, none of the proponents of alternative init system seem > > to have expended much energy in seeking wide deployment of their > > solutions within Debian (or, with the exception of upstart, even > > updating the policy manual) before this binding ruling was sought. > > […] can I ask how you arrived at the conclusion > that not much energy has been expended on upstart in Debian? > > I've actually spent quite a lot of time and energy on getting upstart, and > other base system packages, into a state that users should be able to switch > from sysvinit to upstart without regressions. That means getting the > ifupdown integration in place, making sure lvm and network filesystems work > at boot, ensuring transparent handling of startpar dependencies on scripts > that are shadowed by native upstart jobs, etc.
Sorry, that wording was probably unclear. I *do* know you have done lots of work on upstart in Debian, that's why I also included the point about the policy update. But here I didn't mention, on purpose, work done on specific init systems themselves, helpers and immediate surroundings, but on "wide deployment". I didn't mean to devalue the work you and other upstart supporters have done (or other init system alternative supporters for that matter), I'm sorry that might have been your impression. > It does *not* mean doing > very much work on pushing native upstart jobs to maintainers of leaf > packages; that should be secondary to getting a complete and correct base > into Debian. But we certainly are at the point today where such jobs can be > implemented more widely in packages. > > If you have a different standard for "seeking wide deployment", I'm > interested to know what it is. Well, for example, only just very recently it got to a point where upstart could be installed w/o scary essential removal prompts and similar (again, work that you did). And yes, when I mentioned "seeking wide deployment", I meant archive wide support. Let me try to give an analogy to clarify what I mean. Say, the GNU/kFooBar porters might have invested lots of effort into their kernel, toolchain and kFooBar-specific utilities, which in addition might be in excellent shape; but if the architecture only has 10% packages built for that port, and they stop there, then it cannot get exposure of its possible features, advantages or different ways to do things, and people interested in particular packages might not see the point in even giving it a try. Expecting the project at large to do the other 90% of the porting seems unrelalistic, even if the system has a very solid foundation, because at this point it might not show much advantage to the current ones. Instead I think the work that many porters have done, by sending patches to port packages to their systems, have in many cases triggered curiosity to the point of people possibly experimenting with those ports, or at least seeing value in supporting these even by themselves. There's probably many other similar examples, like having excellent cross-building support in the toolchain but having no actual cross-buildable package in the archive, etc. In the upstart case, most of the work could have been reused from Ubuntu, w/o interfering with the current init system default. I seem to understand reluctance to push native upstart jobs into Debian was partially out of respect towards the project. I just think that respect was misplaced for something that was optional, and it actually backfired. Hope that clarifies. Thanks, 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/20140119163246.ga4...@gaara.hadrons.org