A better illumos...
If you follow illumos very closely, you may already know some of this.
Several months ago, I forked illumos-gate (the primary source code repository for the kernel and system components of illumos) into illumos-core.
I had started upstreaming my work from illumos-core into illumos-gate. I've since ceased that effort, largely because I simply have no time for the various arguments that my work often generates. I think this is largely because my vision for illumos is somewhat different from that of other folks, and sadly illumos proper lacks anything resembling a guiding vision now, which means that only entirely non-contentious changes can get integrated into illumos.
However, I still want to proceed apace with illumos-core, because I believe that work has real value, and I firmly believe that my vision for illumos is the one that will lead to greater adoption by users, and by distributors as well, since much of what I'm trying to achieve in illumos-gate is aimed at reducing barriers to adoption and to developers both of illumos itself and of systems that want to build on top of or integrate illumos. (An example of reducing barriers to adoption -- I recently implemented a BSD compatible flock() within libc, which is sometimes used by applications developed for BSD or Linux.)
I do also invite other parties to cherry-pick from illumos-core into illumos-gate. I suspect that a large number of the enhancements I've made, such as the support for the fexecve() function specified by POSIX 2008, are likely to be more widely useful. Within illumos-core, I want to retain a high standard of quality, and facilitate the effort of upstreaming for those who want to make the effort to do so.
I do want to reiterate that unlike other projects that have forked from illumos, it is not my intent to divorce myself from the community -- rather I see this illumos-core as an experimental branch aimed at exploring new directions that I ultimately hope will be embraced by the wider illumos community some day; by doing this in a separate repository/branch/fork, illumos-core can drive towards these goals without getting mired in questions that would prevent progress on these goals within illumos-gate proper.
The focus here is on delivery, rather than on discussion. (In fact, one of my taglines on social media has for many years been "Code first, questions later." The illumos-core effort represents a return to that core value.)
I'm also interested in having co-collaborators on this project. The goals are large, and while I hope to achieve them someday even if I have to do it all myself, I'm certain that the project will move quite a lot faster with help. Also, because of our lack of bureaucracy, I hope that illumos-core can be an easier path to integration than illumos-gate. I just use a simple github pull-request for integration at present.
There is an opportunity for folks at all different technical levels to participate. We need work that involves systems programming, but also there is work around documentation, research, shell scripting, test development and release engineering to be performed. I'm happy to mentor folks who want to help out, based on their skill level.
And, of course, for folks who want to focus primarily on improving illumos-gate upstream, there is effort that could be spent to figure out what to cherry-pick and to do the various illumos-gate process wrangling steps to get those bits integrated.
A New Fork
Several months ago, I forked illumos-gate (the primary source code repository for the kernel and system components of illumos) into illumos-core.
I had started upstreaming my work from illumos-core into illumos-gate. I've since ceased that effort, largely because I simply have no time for the various arguments that my work often generates. I think this is largely because my vision for illumos is somewhat different from that of other folks, and sadly illumos proper lacks anything resembling a guiding vision now, which means that only entirely non-contentious changes can get integrated into illumos.
However, I still want to proceed apace with illumos-core, because I believe that work has real value, and I firmly believe that my vision for illumos is the one that will lead to greater adoption by users, and by distributors as well, since much of what I'm trying to achieve in illumos-gate is aimed at reducing barriers to adoption and to developers both of illumos itself and of systems that want to build on top of or integrate illumos. (An example of reducing barriers to adoption -- I recently implemented a BSD compatible flock() within libc, which is sometimes used by applications developed for BSD or Linux.)
Relationship to Upstream
I do also invite other parties to cherry-pick from illumos-core into illumos-gate. I suspect that a large number of the enhancements I've made, such as the support for the fexecve() function specified by POSIX 2008, are likely to be more widely useful. Within illumos-core, I want to retain a high standard of quality, and facilitate the effort of upstreaming for those who want to make the effort to do so.
I do want to reiterate that unlike other projects that have forked from illumos, it is not my intent to divorce myself from the community -- rather I see this illumos-core as an experimental branch aimed at exploring new directions that I ultimately hope will be embraced by the wider illumos community some day; by doing this in a separate repository/branch/fork, illumos-core can drive towards these goals without getting mired in questions that would prevent progress on these goals within illumos-gate proper.
The focus here is on delivery, rather than on discussion. (In fact, one of my taglines on social media has for many years been "Code first, questions later." The illumos-core effort represents a return to that core value.)
Call for Participation
I'm also interested in having co-collaborators on this project. The goals are large, and while I hope to achieve them someday even if I have to do it all myself, I'm certain that the project will move quite a lot faster with help. Also, because of our lack of bureaucracy, I hope that illumos-core can be an easier path to integration than illumos-gate. I just use a simple github pull-request for integration at present.
There is an opportunity for folks at all different technical levels to participate. We need work that involves systems programming, but also there is work around documentation, research, shell scripting, test development and release engineering to be performed. I'm happy to mentor folks who want to help out, based on their skill level.
And, of course, for folks who want to focus primarily on improving illumos-gate upstream, there is effort that could be spent to figure out what to cherry-pick and to do the various illumos-gate process wrangling steps to get those bits integrated.
Comments