We are, Argo Technologie SA, are using DilOS platform for business needs. it was very hard to contribute changes related for DilOS needs because I was asking to use illumos based tools like: echo, ed, etc - they are no compatible with GNU coreutils, GNU find, GNU grep, GNU sed, etc... but i have provided solutions to be a more universal, where we can use another tools.
it is example, where is very hard to be a part with illumos changes, because in business, we have to use similat tools on different platforms with less reworks. I have several questions. 1. Can illumos accept changes for distribution with #ifdef <DISTRIBUTION> #endif ? because with DilOS we prefer to use another logic in zones and BE. example of some changes with #ifdef: https://bitbucket.org/dilos/dilos-illumos/commits/1f0c193cc1a31345fd0f3875fe496bbb963e2261 2. Can illumos accept to use another bulid tools for distribution needs with distribution target? example: identify distribution variable in Makefiles and use it only for special distribution. 3. we are, Argo Technologie SA, wants to working on support of Russian SPARC based platforms. right now - R1000 = sun4u. http://www.elbrus.ru/arhitektura_sparc (yes, it is text on Russian, but info about SPARC R1000 can be found in English) new one - https://ru.wikipedia.org/wiki/МЦСТ-R2000 will illumos advocates are interested in updates? the same question about Xen - if advocates cant check it - how to contribute it ? What about distribution specific changes in illumos tree ? is it possible ? right now only one way is possible - support of personal fork. We are not interested in vanila illumos as is right now and it is real overhead to do some tests outside of our distribution, but is we can use illumos sources with our changes, it can be more interest. we are not using IPS based platform, and some others illumos tools for build env. -- best regards, Igor Kozhukhov CTO Argo Technologie SA > On Dec 19, 2018, at 8:12 PM, Garrett D'Amore <[email protected]> wrote: > > In the case of Toomas, just approval by the other advocates backed by a > little bit of process training (it’s not much, but we want all the advocates > following the same process) — note that giving him these bits also would > allow him to act as an advocate (approver) for changes from other people. > Joshua has been working to make some larger changes to the process… so one of > the thoughts that it might not be perfect timing to bring on new advocates if > we’re going to completely change the process and perhaps even fundamentally > change what it means to be an RTI advocate. > > While I started the illumos community, today I’m just one voice of many, and > while I have slightly more influence over the project, it is merely as a > coequal member of the developer-council and RTI advocates list. > > I really really believe that the current processes we follow have hampered us > — it is definitely too difficult for even small and obvious changes to be > made, and the process has slowed much of the interesting progress to a crawl. > The other thing is that we operate almost completely on consensus, with no > real way for coping with disagreement. Which means that “controversial” > changes are very difficult for us to accept, even if the matter is only > controversial to a vanishingly small minority. For example, we carry quite a > bit of baggage (performance penalties!) to accommodate a single closed-source > NIC that is only available for legacy SPARC systems. A couple of years ago I > proposed just ditching that support, but people complained, and so I > abandoned that effort. This is a somewhat recurring theme, and other people > have run up against it. > > The RTI advocacy process is baggage from the Sun days, and while I had the > best of intentions when I established it as the way for illumos, it’s time to > send it off to retirement. > > Fundamentally I also believe it is time to disband the developer-council > which has proven completely and utterly ineffectual (no real decision has > ever been made by that council since its inception, other than the decision > not to make decisions!), and reconstitute a *true* technical architecture > board to provide real technical leadership and steering. It’s very important > that said board not be overpopulated with individuals from one or two > remaining primary illumos corporate consumers, but instead reflect some > diversity of use. (Having said, that, I also think its important that we > don’t wind up picking people who want illumos to remain the > Solaris/SPARC-nostalgia-OS of the 90s and early 00s.) > > Personally, I can think of a number of parties I’d nominate to this “new” > architecture council. Probably a subset of the current RTI advocates, but > also an expanded number of people who aren’t. Pretty much none of the > developer-council (perhaps also including myself in that exclusion, though if > I’m completely honest I’d like to come back and participate in a > reinvigorated illumos community and an architectural council that was > interested in actually leading illumos forward). > > At the end of the day, if we can’t address these hinderances and invigorate > new development, then the project is probably doomed — whether that be to die > off completely or to become the zombie child of one or two remaining > corporate contributors. > > - Garrett > On Dec 19, 2018, 8:40 AM -0800, John Levon <[email protected]>, wrote: >> On Wed, Dec 19, 2018 at 08:27:34AM -0800, Joshua M. Clulow wrote: >> >>>> At November 3rd, Joshua Clulow did post the mail to advocates list >>>> with subject: "Proposals for Project Improvements”, with few people >>>> responded, almost 2 months later, there are *NO* resulting action >>>> taken. The project state has been discussed over and over, >>>> developers are not happy and yet nothing has changed. >>> >>> That's simply false. For starters, I've opened the "illumos Project >>> Discussion" repository: >>> >>> https://github.com/illumos/ipd >>> >>> There are two IPDs so far, and I'm personally encouraging people who >>> have ideas for projects to write their own IPDs as we work out exactly >>> how this will look with more participants. As we get a couple of >>> these under way, I expect to put a bit more process in place and make >>> broader announcements. >>> >>> The first IPD is one I wrote, detailing the list of things I need to >>> sort out in the operating system to prepare for the kind of automated >>> build-and-test environment that we want. I've also been working on >>> those bugs. Once I have those knocked out and integrated, I'll be >>> looking at the automatic build environment. >> >> In the hope of something productive: what is currently in the way of handing >> out >> commit bits to people like Toomas so they can push-after-approval? This >> seems like near-zero-cost change, and I don't recall any controversy. >> >> regards >> john >> >> ------------------------------------------ >> illumos: illumos-developer >> Permalink: >> https://illumos.topicbox.com/groups/developer/Td3185838722eb01a-M351f4f8f29c51c24f26a9fd2 >> Delivery options: https://illumos.topicbox.com/groups/developer/subscription > > illumos <https://illumos.topicbox.com/latest> / illumos-developer / see > discussions <https://illumos.topicbox.com/groups/developer> + participants > <https://illumos.topicbox.com/groups/developer/members> + delivery options > <https://illumos.topicbox.com/groups/developer/subscription>Permalink > <https://illumos.topicbox.com/groups/developer/Td3185838722eb01a-M4cf7647b015c4bbaab582db0> ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T03dff29b8e1125f4-Mae008f932fbd81c980db1d2c Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
