Re: [OmniOS-discuss] Questions about - End the uncertainty -
Only a personal stance I am from Germany where a re-unification of Germany happened some year ago. When this happened there were a lot of different interest involved but luckily Cancellor Kohl simply declared this as a golden common future for East and West Germany and he succeeded. A lot went wrong afterwards and for some it was indeed not the golden future. But in general, Germany is seen now much better than in any other history. Mr Kohl dies recently with the honour of the first funeral as a European state ceremony. Illumos is not nearly as relevant like the future of nations involved in wars. But the mood of the persons and the needed decisions are similar. Lets repeat a similar success with OI + OmniOS despite the problems and differences. They are sisters and want basically the same. In the end both will be better off. Just do it. Gea @napp-it.org ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Questions about - End the uncertainty -
On July 7, 2017 5:01:59 PM GMT+02:00, Michael Rasmussen wrote: >On Fri, 7 Jul 2017 16:31:41 +0200 >Guenther Alka wrote: > >> >> Maybe a switch to the OI installer is desirable as it offers a >network setting option on initial setup. >> The OmniOS installer is annoying regarding this >> >> >I have raised an issue against the kayak installer regarding this and a >solution as well. See https://github.com/omniosorg/kayak/issues/1 Ironically, IMHO the choice of installers is the least of our problems here :) I mean, IMHO this only(?) plays a role during distro-construction, so it is a matter of one or another tweak in a recipe - of which we can have several for different media sets - with same repo (fruit of same shared effort) used for os/net (variants?) and for other application packages. Perhaps in the end we can just improve to common taste and keep one installer. But are not bound to do so. Jim -- Typos courtesy of K-9 Mail on my Redmi Android ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Questions about - End the uncertainty -
On Fri, Jul 7, 2017 at 2:52 PM, Michael Rasmussen wrote: > Add to this that the user should be able to apply a preseed to the > installer (Think of Debian) to have all that done automatically - > imagine being able to remote install through PXE both Omnios and > detailed configuration and installation of extra stuff. This is already possible via the `Postboot` functionality in Kayak, e.g.: Postboot '/sbin/ipadm create-addr -T dhcp e1000g0/v4' Just as with the old Solaris Jumpstart or AI, you can do this in configs that are specific to a single machine (by MAC address) or multiple machines (MAC prefix). You can do pretty much any commands here, and they get run by the once-at-first-boot service, svc:/system/initial-boot [1][2] One caveat is that this runs after the single-user milestone, so pretty early in the boot, before networking and all filesystems are available. If you need to install additional packages, for instance, you should look into some supplemental method of configuration management. Eric [1] SMF manifest: https://github.com/omniosorg/illumos-omnios/blob/master/usr/src/cmd/svc/milestone/initial-boot.xml [2] SMF method script: https://github.com/omniosorg/illumos-omnios/blob/master/usr/src/cmd/svc/milestone/initial-boot ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Questions about - End the uncertainty -
Thank you Dan Does this mean - the problems around a cooperatione with OmniOS were mainly in the past prior OI Hipster? - A a merge would introduce conflicts. This would require work to solve or both sides agree to use one or the other as base? Each choice would require work to maintain the current features. Installer seems irrelevant for me unless it offers what is needed. Your last comment is the core of the problem. How to coordinate communities! Gea @napp-it.org Am 07.07.2017 um 20:02 schrieb Dan McDonald: On Jul 7, 2017, at 11:42 AM, Guenther Alka wrote: hello Dan Thanks for jumping in. You are the person with the very best insights in OmniOSand Illumos and propably OI. Can you please comment about the options to cooperate with OI. Is this doable and wishable from your point of viewand how or do you have an alternative idea for a positive future of OmniOS ce or free Illumos based general use servers in general.Are there concerns for a project merge? I had a unicast chat session with someone about this recently. it's *POSSIBLE*, but remember the half the reason OmniOS happened in the first place was because OI focussed way too much on the desktop and all that accompanies it. (The other half, not keeping up with upstream, was fixed by Hipster.) I don't have the cycles to spell out how an OI/OmniOS merge MIGHT happen. There are three big technical problems that come to mind: 1.) Package naming: There are some subtle differences in IPS package names outside of illumos between the two. 2.) Perl & Python: OmniOS picked dual-mode perl and dual-mode Python (64 and 32 bit). Not sure what OI does. 3.) Installer: I chose to abandon Caiman in no small part because it was far more bloated than it needed to be for OmniOS. I wish I'd done Kayak for ISO sooner (or Theo or Eric did). I believe there is a decent post-processing step that can be done for Kayak Interactive that can provide the functionality of the old Caiman or OI/slim_install. Beyond that, there's the headaches of community coordination, etc. All of this I don't have cycles for, I can say for sure. Sorry, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Questions about - End the uncertainty -
On 7/7/17 1:52 PM, Michael Rasmussen wrote: On Fri, 7 Jul 2017 11:14:25 -0400 Dan McDonald wrote: During the r151024 timeframe, one of the things on my plate was going to be a "install postprocessing" menu option on the Kayak menu. The idea would be if you wanted to get things set prior to your next boot, you'd go into that. It seemed appropriate for an interactive installer, while still keeping the spirit of REALLY FAST, DAMMIT that Kayak embodied. My suggestion, and you can dismiss it of course, it to build the postprocessing menu option. It'd bring up a new screen, full of choices like "configure networking", "Set root password", "Add users", etc. etc. This is exactly the same ideas I have;-) Add to this that the user should be able to apply a preseed to the installer (Think of Debian) to have all that done automatically - imagine being able to remote install through PXE both Omnios and detailed configuration and installation of extra stuff. Yea, I thought that was what AI was? ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Questions about - End the uncertainty -
On Fri, 7 Jul 2017 11:14:25 -0400 Dan McDonald wrote: > During the r151024 timeframe, one of the things on my plate was going to be a > "install postprocessing" menu option on the Kayak menu. The idea would be if > you wanted to get things set prior to your next boot, you'd go into that. It > seemed appropriate for an interactive installer, while still keeping the > spirit of REALLY FAST, DAMMIT that Kayak embodied. > > My suggestion, and you can dismiss it of course, it to build the > postprocessing menu option. It'd bring up a new screen, full of choices like > "configure networking", "Set root password", "Add users", etc. etc. > This is exactly the same ideas I have;-) Add to this that the user should be able to apply a preseed to the installer (Think of Debian) to have all that done automatically - imagine being able to remote install through PXE both Omnios and detailed configuration and installation of extra stuff. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -- /usr/games/fortune -es says: I have a rock garden. Last week three of them died. -- Richard Diran pgpacr2umgEpf.pgp Description: OpenPGP digital signature ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Questions about - End the uncertainty -
> On Jul 7, 2017, at 11:42 AM, Guenther Alka wrote: > > hello Dan > > Thanks for jumping in. > You are the person with the very best insights in OmniOSand Illumos > and propably OI. Can you please comment about the options to cooperate with > OI. > > Is this doable and wishable from your point of viewand how or do you have > an alternative idea for a positive future of OmniOS ce or free Illumos > based general use servers in general.Are there concerns for a project merge? I had a unicast chat session with someone about this recently. it's *POSSIBLE*, but remember the half the reason OmniOS happened in the first place was because OI focussed way too much on the desktop and all that accompanies it. (The other half, not keeping up with upstream, was fixed by Hipster.) I don't have the cycles to spell out how an OI/OmniOS merge MIGHT happen. There are three big technical problems that come to mind: 1.) Package naming: There are some subtle differences in IPS package names outside of illumos between the two. 2.) Perl & Python: OmniOS picked dual-mode perl and dual-mode Python (64 and 32 bit). Not sure what OI does. 3.) Installer: I chose to abandon Caiman in no small part because it was far more bloated than it needed to be for OmniOS. I wish I'd done Kayak for ISO sooner (or Theo or Eric did). I believe there is a decent post-processing step that can be done for Kayak Interactive that can provide the functionality of the old Caiman or OI/slim_install. Beyond that, there's the headaches of community coordination, etc. All of this I don't have cycles for, I can say for sure. Sorry, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Questions about - End the uncertainty -
hello Dan Thanks for jumping in. You are the person with the very best insights in OmniOSand Illumos and propably OI. Can you please comment about the options to cooperate with OI. Is this doable and wishable from your point of viewand how or do you have an alternative idea for a positive future of OmniOS ce or free Illumos based general use servers in general.Are there concerns for a project merge? best regards Gea @napp-it.org Am 07.07.2017 um 17:14 schrieb Dan McDonald: On Jul 7, 2017, at 11:01 AM, Michael Rasmussen wrote: Maybe a switch to the OI installer is desirable as it offers a network setting option on initial setup. The OmniOS installer is annoying regarding this I switched the OmniOS installer AWAY from Caiman because I wanted to disentangle from Python. During the r151024 timeframe, one of the things on my plate was going to be a "install postprocessing" menu option on the Kayak menu. The idea would be if you wanted to get things set prior to your next boot, you'd go into that. It seemed appropriate for an interactive installer, while still keeping the spirit of REALLY FAST, DAMMIT that Kayak embodied. My suggestion, and you can dismiss it of course, it to build the postprocessing menu option. It'd bring up a new screen, full of choices like "configure networking", "Set root password", "Add users", etc. etc. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss -- ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Questions about - End the uncertainty -
> On Jul 7, 2017, at 11:01 AM, Michael Rasmussen wrote: > >> Maybe a switch to the OI installer is desirable as it offers a network >> setting option on initial setup. >> The OmniOS installer is annoying regarding this I switched the OmniOS installer AWAY from Caiman because I wanted to disentangle from Python. During the r151024 timeframe, one of the things on my plate was going to be a "install postprocessing" menu option on the Kayak menu. The idea would be if you wanted to get things set prior to your next boot, you'd go into that. It seemed appropriate for an interactive installer, while still keeping the spirit of REALLY FAST, DAMMIT that Kayak embodied. My suggestion, and you can dismiss it of course, it to build the postprocessing menu option. It'd bring up a new screen, full of choices like "configure networking", "Set root password", "Add users", etc. etc. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Questions about - End the uncertainty -
On Fri, 7 Jul 2017 16:31:41 +0200 Guenther Alka wrote: > > Maybe a switch to the OI installer is desirable as it offers a network > setting option on initial setup. > The OmniOS installer is annoying regarding this > > I have raised an issue against the kayak installer regarding this and a solution as well. See https://github.com/omniosorg/kayak/issues/1 -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -- /usr/games/fortune -es says: Q: "What is the burning question on the mind of every dyslexic existentialist?" A: "Is there a dog?" pgpX3K3nKk_nV.pgp Description: OpenPGP digital signature ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Questions about - End the uncertainty -
Hello Jim and @all I am using OmniOS and OI for years and I fully agree with you. Your position and that of Aurélian and Tobi are not identical but not too far away and may be the base to find a solution for a win-win situation for all that suits the needs and wants of all. In the current lifecycle, no question; we need a continuation of OmniOS 151022 and OI in their current state as there are many users around. But then it seems increditable stupid if the next OmniOS and OpenIndiana are based on a whole different base, distribution, infrastructure or promotion and this discussion really offers some new oportunities due the "revival" on OmniOS-ce side. I am not involved in either OS distribution so you may correct me on wrong statements but as I see: *OmniOS and OI Hipster Text are nearly identical in core functions and stability as this is inherited from Illumos* OI is quite vanilla Illumos while OmniOS is based on a copy as a freeze or subset of Vanilla Illumos with LX as addon? If this is right, the more valuable part is the OmniOS clone when it comes to LX, continuation and stablity. Using OI current as common base would require to create a new stable clone and work to integrate LX, much more work to do and we have this aleady done in OmniOS. Adding the current OI featureset seems possible on top of Vanilla Ilumos and OmniOS Illumos. *Is this possible or an option?* *What is the stance of OI to use OmniOS-Illumos as source instead of Vanilla Illumos?* This will give both the current stable base where common work is done while OI has the option to add the full set of its current add-ons via a repository, not to forget that for me a GUI for local filemanagement and storagemanagement is a very valuable add-on for a server. Both are using in such a scenario one stable core stable/lts repository every 6 months like currently - similar or smaller than the current OmniOS and adds extra functionalities by an extended repository that adds an enhanced featureset. The rest is simple *OI is an established distribution with a small but working team to maintain and build a distribution, a known name and website, **a wiki, download and repo mirrors etc, a common project should be based upon using OpenIndiana as common roof? The difference may be only in OI-Hipster (general use server or desktop) vs OI-OmniOS_ce (minimal stable storage server) with two distributions Text (OI-OmniOS_ce and a base repo) and GUI (OI Hipster, the same but with GUI and other services due an additional enhanced repo)* No need to duplicate work. Even if both sides are requested to compromise, both wins. All current and new manpower can be used to make the common project better or extend it for more use cases. Maybe a switch to the OI installer is desirable as it offers a network setting option on initial setup. The OmniOS installer is annoying regarding this comments? Gea @napp-it.org Hello all, I posted my opinion and advice in the lobby, but just in case the mailing list has more visibility so far, would like to repeat or expand a few points here. Especially as I tinker with both OpenIndiana and OmniOS based systems so can hopefully see how to bridge some gaps and benefit from commonalities. First of all - kudos and best of luck in your effort. Indeed, keeping existing systems afloat and up-to-date is an important priority, and there are quite a few interesting and important technical issues to take care of even if the workflow and system structure stays as unchanged as possible. Also, the well-earned perception of OmniOS releases as a dependable, feature-full and unbloated OS, both for use "as is" and as a foundation for further value-added products that some teams work on, is also valuable to keep and uphold. Unfortunately, as seen from these recent discussions too, this stance sort of robs away most of the same values, unjustly, from OpenIndiana (we mean rolling Hipster, not old stale "dev"). Kind of childish "we are good, so others must be worse or outright bad" and kind of misinformed "we know little of that, so it must be unworthy of attention" or that it is a bloated desktop distro vs. minimal server one. These two general-purpose distros share more than what they differ in, compared to say SmartOS or Delphix or Nexenta who chose to excel in particular directions and sort of neglect or forbid others (e.g. installation of random software on a filer, making it also a big-data processing machine or a standalone home firewall, dev rig, webserver and downloader of stuff). For my part, I don't want to keep choosing which of the two distros to base my next rig on, given they are almost the same except this tiny bit here or there... In fact, OI never was 'just a desktop distro' of arguable stability. The "dev" version is dead-stable ;) while the current focus of activity, OI Hipster, is very comparable to OmniOS Bloody - just a lot more active, with do
Re: [OmniOS-discuss] Questions about - End the uncertainty -
On July 7, 2017 7:21:37 AM GMT+02:00, Tobias Oetiker wrote: >Hi Aurélien > >the motivation behind OmniOSce is that we have come to love the the >stability and >tight focus of OmniOS. Many of us are running large servers that form >critical pieces of our infrastructure. Loosing OmniOS was simply not an >option for us. Since OmniTI gave up on this we were forced start doing >the work on our own. > >for now our focus is in building on Dan's excellent work, both in >updating r022 as well as pulling in new stuff from both upstream >illumos and joyents lx work. > >we are happy for anyone to join us in our effort, for example also in >providing a more end user focussed repo that goes along with omnios, >providing a desktop environment for those who want to use the os in >that capacity. > >www.omniosce.org >gitter.im/omniosorg/Lobby > >Tobias Oetiker > >> On 7 Jul 2017, at 01:47, Aurélien Larcher > wrote: >> >> >> >>> Gea, >>> >>> the king is dead, long live the king >>> >>> https://gitter.im/omniosorg/Lobby >>> >>> www.omniosce.org >>> >>> the story continues ... >> >> It is good news, but I would engage you to discuss about reducing the >fragmentation in the illumos community. >> We have a few distros maintained by 1-3 guys without any or much >momentum and much duplication of efforts (Debian has 1000+ devs working >together and we are barely able to have more than 10). >> >> We should join our efforts like, as I suggested, basing on common >tools and userland. >> I do not see how wasting energy in duplicate efforts will help us >keep/gain momentum. >> I mentioned earlier the possibility of a virtuous circle with OI as >the rolling testing and OmniOS the stable: to be honest I see very >little sense in maintaining two "testing" with such a small manpower. >In the long term this does not seem sustainable. >> >> At least some degree of collaboration should be maintained on >documentation, pkg(5) and updates of Python/Perl/GCC with the same >source repository. >> >> Of course this is not "right now", as you need to maintain >continuity, but we should plan the next 6 month cycle to decide on >common requirements and make it happen. >> I saw Peter has built illumos-omnios on Tribblix, I think we should >do the same on OpenIndiana: the issue is not about doing it once (I did >it last year) but having a person commited to maintain it. >> >> Convergence is necessary, at least to some extent, discussion is >open. :) >> >> Kind regards >> >> Aurélien >> >>> >>> cheers >>> tobi >>> >>> - On Jul 5, 2017, at 4:05 PM, Guenther Alka >wrote: >>> about OmniOS and the silence for weeks >>> >>> For my own future, I have already decided to switch back to >OpenIndiana, the community based sister project of OmniOS. But like >many users, I have yet OmniOS installations running perfectly. For >them, it is essential to ask about the future for the next months or >year and needed next steps (can wait some time or switch as soon as >possible). >>> >>> >>> @OmniTi >>> The end of OmniOS@OmniTi seems final. >>> >>> - How long will the website and the repo remain online? >>> >>> - Is there an option to fix serious bugs or problems in OmniOS >@OmniTi for >>> a limited time like 1 year or at least end of the year? >>> >>> - Are you willing to transfer the website/name either to a new >OmniOS community project (I cannot see this as an option regarding the >silence about) or to the OpenIndiana community to use it as a name for >a possible stable like OpenIndiana Hipster=dev and OpenIndiana OmniOS >as a stable subset? (if OI is willing to go that route but the request >or offer must come from OmniTi or OmniOS people). >>> >>> OmniOS has a very strong reputation regarding production quality and >stability, so such a step would help both if OpenIndiana and OmniOS >would cooperate in a common project. Seems a pity if the name would die >or remain as a name for a failed project. >>> >>> >>> @OmniOS developers (current or former - you have done a very good >job!) >>> >>> - Is there an option to fix serious bugs or problems in OmniOS for a >limited time like 1 year or at least end of the year? This would help >until a sucessor (less likely OmniOS 151024, maybe next OpenIndiana >snap with a stable subset) is available. LX would then remain an OmniOS >option in the meantime (I would not dare to ask about an upstream). >>> >>> >>> >>> @all >>> comments? >>> >>> >>> >>> Gea >>> @napp-it.org >>> >>> ___ >>> OmniOS-discuss mailing list >>> OmniOS-discuss@lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >>> >>> -- >>> Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, >Switzerland >>> www.oetiker.ch t...@oetiker.ch +41 62 775 9902 >>> >>> ___ >>> OmniOS-discuss mailing list >>> OmniOS-discuss@lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >>> >> >> >> >> --
Re: [OmniOS-discuss] Questions about - End the uncertainty -
On Fri, Jul 7, 2017 at 10:24 AM, Peter Tribble wrote: > > > On Fri, Jul 7, 2017 at 12:47 AM, Aurélien Larcher < > aurelien.larc...@gmail.com> wrote: > >> It is good news, but I would engage you to discuss about reducing the >> fragmentation in the illumos community. >> We have a few distros maintained by 1-3 guys without any or much momentum >> and much duplication of efforts (Debian has 1000+ devs working together and >> we are barely able to have more than 10). >> >> We should join our efforts like, as I suggested, basing on common tools >> and userland. >> I do not see how wasting energy in duplicate efforts will help us >> keep/gain momentum. >> > > I don't actually see significant duplication of effort. In the case of OI > and OmniOS, there's not much overlap because the work is in > completely separate areas. > Not much overlap as in server use? > > Each community or distro does work that largely falls into 2 categories: > work that's only relevant to that community, or work that, because it's > all open source and published, can easily be picked up by someone else. > How about lowering the barrier to make "easily" easier? > > >> I mentioned earlier the possibility of a virtuous circle with OI as the >> rolling testing and OmniOS the stable: to be honest I see very little sense >> in maintaining two "testing" with such a small manpower. In the long term >> this does not seem sustainable. >> > > Attempting to coerce 2 projects together is even worse; each is then > compromised by having to work not only to its own rules and schedule > but has to fit in with the other project too. > > You have the relationship between OI and OmniOS inverted, I think. > The only merge I can see making sense is for OI to rebase on > illumos-omnios rather than illumos-gate - in which case OI is a downstream > derivative of OmniOS. > Interesting > > (The situation of OmniOS being the "stable" branch of OI is unlikely to > work. Apart from the philosophical and technical incompatibilities, it's > relatively easy to have an unstable/testing branch of a stable project, > but it's hard to take a rolling testing project and build a stable project > on top of it. Besides, that would require OI to do an awful lot of work > in terms of backporting/release engineering/testing and the like that > isn't directly relevant to them which would then have to be duplicated > downstream as well.) > > Generally, if you have mature intelligent people forming communities > they will naturally form reasonably optimal structures. People tend to > make choices that make it easier for them to make progress. (Yes, it's > a local maximum rather than a global one.) Telling people what they > ought to do tends not to be well received; if you want to change the > behaviour of people or the structure then you need to game the system > to give people better options than the one they've currently chosen. > Being too enthusiastic can be interpreted in a negative way. Discussing the possibilities seems is indeed unreasonable since coercion should be avoided at all cost and most likely nothing will work out. You are right, sorry for the disturbance. Let us move along in the saddle point. Kind regards, Aurélien Cheers, > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ > -- --- Praise the Caffeine embeddings ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Questions about - End the uncertainty -
On Fri, Jul 7, 2017 at 12:47 AM, Aurélien Larcher < aurelien.larc...@gmail.com> wrote: > It is good news, but I would engage you to discuss about reducing the > fragmentation in the illumos community. > We have a few distros maintained by 1-3 guys without any or much momentum > and much duplication of efforts (Debian has 1000+ devs working together and > we are barely able to have more than 10). > > We should join our efforts like, as I suggested, basing on common tools > and userland. > I do not see how wasting energy in duplicate efforts will help us > keep/gain momentum. > I don't actually see significant duplication of effort. In the case of OI and OmniOS, there's not much overlap because the work is in completely separate areas. Each community or distro does work that largely falls into 2 categories: work that's only relevant to that community, or work that, because it's all open source and published, can easily be picked up by someone else. > I mentioned earlier the possibility of a virtuous circle with OI as the > rolling testing and OmniOS the stable: to be honest I see very little sense > in maintaining two "testing" with such a small manpower. In the long term > this does not seem sustainable. > Attempting to coerce 2 projects together is even worse; each is then compromised by having to work not only to its own rules and schedule but has to fit in with the other project too. You have the relationship between OI and OmniOS inverted, I think. The only merge I can see making sense is for OI to rebase on illumos-omnios rather than illumos-gate - in which case OI is a downstream derivative of OmniOS. (The situation of OmniOS being the "stable" branch of OI is unlikely to work. Apart from the philosophical and technical incompatibilities, it's relatively easy to have an unstable/testing branch of a stable project, but it's hard to take a rolling testing project and build a stable project on top of it. Besides, that would require OI to do an awful lot of work in terms of backporting/release engineering/testing and the like that isn't directly relevant to them which would then have to be duplicated downstream as well.) Generally, if you have mature intelligent people forming communities they will naturally form reasonably optimal structures. People tend to make choices that make it easier for them to make progress. (Yes, it's a local maximum rather than a global one.) Telling people what they ought to do tends not to be well received; if you want to change the behaviour of people or the structure then you need to game the system to give people better options than the one they've currently chosen. Cheers, -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
