Nirbheek Chauhan posted on Mon, 05 Jul 2010 09:02:19 +0530 as excerpted: > On Mon, Jul 5, 2010 at 7:53 AM, Richard Freeman <ri...@gentoo.org> > wrote: >> On 07/04/2010 04:09 PM, Jory A. Pratt wrote: >>> >>> For those of you not on the #gentoo-dev channel, I just announced I am >>> gonna be looking at the openrc code and fixing the bugs and working to >>> continue the development. Anyone that is interested in helping please >>> feel free to contact me off list to discuss how we will handle getting >>> openrc back on track.
Very cool. =:^) If you/we're moving OpenRC development back in-house, a couple of the problems with OpenRC as it was, pretty much cease to exist any more. The problems with OpenRC first trace back to, from what I can see, a disagreement some years ago, now -- which also played a non-minor role in Roy leaving Gentoo, as well. Roy's idea was to take Gentoo toward POSIX shell compatibility, both init-system-wise and package-system-wise. Over- all, that went over like a lead balloon, a number of devs (including several core toolchain, etc, devs, and council members) /liked/ the bash extensions Gentoo relies on, and our package system remains solidly bash dependent today, both by policy and in practice. But Roy was the baselayout (then including what's now openrc as well) maintainer, and he went ahead with his plans there, splitting baselayout into the Gentoo specific baselayout, and the init system itself, which was intended to be POSIX shell compliant and distribution and *nix system independent, as well as implementing core parts of it as native executables, thus speeding it up dramatically from the formerly almost entirely shell scripted implementation. In large part (at least from the view from here as a user of the new system) it was due to the goals of POSIX shell compatibility and distribution agnosticism that delayed and drew out OpenRC development and stabilization so much, the reason why every time it seemed about ready to go stable, along would come new versions with dramatic changes, dropping more bashisms/gentooisms, or fixing bugs in the implementation triggered by the last round of drops. Had the only or primary goal been simply the split and the switch to the native code core, many of the changes, for instance to the network subsystem, wouldn't have been necessary, and the more parallel reliable and faster native code system would have been able to stabilize far sooner. But it would seem that whatever other distributions or BSDs he had hoped to get using OpenRC went with something else, instead, and as Gentoo has continued down the GNU/bash based system route, his interests and those of Gentoo have continued to diverge as well, so the OpenRC project has apparently become a dead-end as far as his interest is concerned, and he's abandoning it. Too bad for what could have been for OpenRC, but bringing it back in-house does solve the two biggest problems Gentoo was having with it, all the unnecessary (from a Gentoo perspective) changes removing bashisms and gentooisms, and the fast rate of incompatible change, leaving Gentoo without a practical base for stabilizing anything. >> Well, openrc isn't any worse than baselayout-1 for upstream support. >> However, I do agree that we should strongly try to standardize on >> something that is more cross-platform if possible. >> >> I'd rather not push to make openrc stable (which means lots of >> migration for users), only to then move to something else anyway. Why >> have two migrations when you can just have one? >> > The reason why people want to do an openrc migration right now is > because we don't know when we'll find something else to move to; make it > work with gentoo, make it work for everyone, iron out all the bugs, and > push it to stable. In all probability, and looking at our past > experience with pushing openrc to stable, it *will* take years. It's too > much work to maintain both baselayout-1 *and* openrc *and* find > something else to move to. It's best to move to openrc (which has > numerous benefits over baselayout-1, and has a maintainer now), and then > see what we can do. Well, given the above and assuming Gentoo could settle on a reasonably mature replacement within a reasonably short period (say 4-6 months), it's possible adopting and stabilizing that replacement wouldn't take the years and years that OpenRC has. Presumably, whatever we were to settle on would already know where it was going, and wouldn't be doing the change-horses-in-mid-stream thing that OpenRC was pulling, killing the bashims, etc, at the same time. But those are some big assumptions. I've gotten the impression that the projects making the big waves aren't all that mature, and while they hopefully aren't changing horses in mid-stream like OpenRC was doing, so the development shouldn't be as painful in that regard, they still have some serious growing to do before they're to the point where OpenRC is, today. Really, even if Gentoo does ultimately switch to something else, we do need to get stable on something a bit more modern than the baselayout-1 we're stuck with ATM, and OpenRC is pretty close to there, particularly since we're bringing it back in-house now, and it'll take some time for our new maintainer to get up to speed on it, so the only right away changes are likely to be what's necessary to fix the remaining bugs and stabilize what we have -- we're not trying to hit a fast changing target, as we were before, and there's nothing to trigger any more of those incompatible changes simply for POSIX compatibility or the like, since Gentoo depending on bash is a settled question at this point. So really, openrc-for-stable it really needs to be, at this point. Once that's for sure a settled question, /then/ we can debate whether Gentoo should try to switch to something more standardized, and what that might be if so, longer term. But what's very likely to be another two years minimum, with no real upper bound at all at this point, on baselayout-1, for stable users, while Gentoo dumps an OpenRC that's very close to stable at this point, to chase after what could well be "the wind" for another two years or more, possibly to realize that's simply not going to work for Gentoo either, or if we force it, it'll be at the expense of serious feature regression, just isn't a good idea, and there's no way to /make/ it a good idea. So let's stabilize OpenRC and be done with it, and /then/ we can debate where we want to go from there. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
