-
Notifications
You must be signed in to change notification settings - Fork 29.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plans for illumos distribution? #841
Comments
Edit: maybe that was solaris |
ATM all the build machines are donated, usually by people concerned about particular operating systems. For instance, Voxer is running their stuff on FreeBSD and they donate the FreeBSD machines, not to mention employing @indutny who will fix any issues that arise. We've talked about it a bit on TC calls before but we are willing to support any operating system provided someone is around to maintain it. We can easily ad support for Illuminos if someone is willing to donate the compute resources for build and some developers to keep it working. |
^ as an addendum to @mikeal's comments, build resources donated to the project must be under the full control of the build team (me specifically at this stage), it's not going to work if we have random people donating computers that we don't have control over for maintenance and security purposes. The situation with Voxer at the moment is that they have given us complete control over a couple of FreeBSD boxes as well as a couple of Mac Minis that they've donated to the project but are sitting behind their firewall and we have VPN access to. |
Yea, and the way it works with most of the other donated resources, like from DigitalOcean, is that they grant us a free account that @rvagg has access to. |
I have pointed modulus.io to this issue and kindly asked if they are interested in donating a SmartOS box for building io.js on SmartOS. I hope that's in their interest since most of their PaaS are on Joyent (iow; SmartOS). |
@trygve-lie thanks. @rvagg are we ok with a SmartOS box that is used only for building releases? In other words, spin it up before we do a release and create the build, then turn it off. If we are fine with this then I could donate a few bucks and just have it run on Joyents public cloud. |
We'd need a box as part of our regular test set as well though, separate from a release machine (although they could be in zones I guess). I'd not feel comfortable publishing binaries for a platform we don't even regularly test on. On-demand is OK I guess but quite a bit of overhead for the build team until we automate it. /cc @iojs/build |
It'd also be good to know we have someone that actively takes care of bugs, test failures or similar stuff that would arise from having a SmartOS machine running the test suite. |
In my opinion, build platforms should have to be owned by a company willing to commit a machine and dev time to keep it stable. There's less chance of it getting abandoned than if it's owned by some individual who just happens to have an interest in that platform at that particular time. |
@Qard I don't think we need to tie those two things together: donation of compute resources and development resources. We can run tests and build for platforms that aren't entirely "supported" in the case that we have compute resources and no development resources. But I do agree with the premise that platforms that don't have anyone who cares about them enough to continue to support them should not be officially "supported." |
True. It could also be at least one company, so you could have one just supplying a machine and some others putting a bit of dev time into it. I'd recommend that be the requirement to call it "officially" supported. I agree that we could be making builds for platforms that we have the compute resources for but no dev resources, but I think it'd be good to clearly define what is officially supported and what only has partial support. I think it'd be appealing to enterprise users to have that rubber-stamp. |
I'm not sure I agree with the use of "company" here. If we're concerned about stickability of the contributors, then we just apply the rule in reverse and remove the platform from our test & release schedule when it no longer has active supporters and we can't get bugs fixed on it in core. |
As it stands we don't have a roster of "dedicated companies" in any form. We have people who spend all their time working on io.js, and are paid by someone to do so, but we don't tally those companies or "officially" rely on them in any way. An increasing amount of work is also being done in smaller bits by more people who are, presumably, not working on io.js "full time." It doesn't make sense to block support or rely, in an official capacity, on "dedicated full time resources" like the project has done in the past. Even in places where we do rely on this (and we surely do in some areas) we'll never get past that if we start to create official policies that are reliant on it. It also sends the wrong message to contributors who don't contribute "full time." If nobody cares enough about something to contribute it, then it won't be supported. That's a fairly simple an straightforward policy that doesn't rely directly on any companies. |
I wasn't implying full-time dev resources just a commitment that, if something breaks, someone will be there to fix it. I definitely agree that the lack of that commitment should not block us from releasing on a particular platform though, just that it should be messaged differently. |
(this issue is somewhat travelling from the original topic) I think that if an already added platform (lets assume SmartOS makes it) deteriorates over time in terms of failed tests or build issues, the build wg should consider removing the "supported" flag. A high quality release for supported platforms should be a prioritised goal. |
Which is one reason you don't see FreeBSD downloads even though they are in our CI mix |
@rvagg what do you need in order to get a build ready? I can add your key to a SmartOS base64 instance and give you the IP in email. Other than that, what do you need? |
@geek perhaps add my keys and email me @ rod@vagg.org, but I may not be the person to set this up so I'll get someone from @iojs/build to put up their hand to help out. |
@rvagg sounds good. I am willing to own the SmartOS build. I requested membership to the working group. Either way, we should be able to provide io.js a SmartOS instance for builds for at least the next year. |
Just a quick update: @geek has joined forces with @iojs/build and has so far set up a smartos vm we will primarily use for being part of the jenkins fleet as a test runner. We're currently running into compile issues, but will hopefully use the results of the test suite to improve SmartOS and Illumos as a first class io.js-citizen. I'm suggesting we close this since the progress initially asked for is underway. |
Closing. Tracking at nodejs/build#60 |
@rvagg do you know if there are plans or objections to adding an illumos distribution for io.js, perhaps even a SmartOS image?
The text was updated successfully, but these errors were encountered: