Skip to content
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

Closed
geek opened this issue Feb 13, 2015 · 21 comments
Closed

Plans for illumos distribution? #841

geek opened this issue Feb 13, 2015 · 21 comments

Comments

@geek
Copy link
Member

geek commented Feb 13, 2015

@rvagg do you know if there are plans or objections to adding an illumos distribution for io.js, perhaps even a SmartOS image?

@Fishrock123
Copy link
Contributor

I think Rod had been looking into getting SmartOS on the CI.

Edit: maybe that was solaris

@mikeal
Copy link
Contributor

mikeal commented Feb 13, 2015

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.

@rvagg
Copy link
Member

rvagg commented Feb 13, 2015

^ 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.

@mikeal
Copy link
Contributor

mikeal commented Feb 13, 2015

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.

@trygve-lie
Copy link

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).

@geek
Copy link
Member Author

geek commented Feb 25, 2015

@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.

@rvagg
Copy link
Member

rvagg commented Feb 25, 2015

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

@jbergstroem
Copy link
Member

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.

@Qard
Copy link
Member

Qard commented Feb 25, 2015

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.

@mikeal
Copy link
Contributor

mikeal commented Feb 25, 2015

@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."

@Qard
Copy link
Member

Qard commented Feb 25, 2015

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.

@rvagg
Copy link
Member

rvagg commented Feb 25, 2015

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.

@mikeal
Copy link
Contributor

mikeal commented Feb 25, 2015

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.

@Qard
Copy link
Member

Qard commented Feb 25, 2015

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.

@jbergstroem
Copy link
Member

(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.

@rvagg
Copy link
Member

rvagg commented Feb 25, 2015

Which is one reason you don't see FreeBSD downloads even though they are in our CI mix

@geek
Copy link
Member Author

geek commented Feb 25, 2015

@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?

@rvagg
Copy link
Member

rvagg commented Feb 25, 2015

@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.

@geek
Copy link
Member Author

geek commented Feb 25, 2015

@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.

@jbergstroem
Copy link
Member

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.

@cjihrig
Copy link
Contributor

cjihrig commented Mar 1, 2015

Closing. Tracking at nodejs/build#60

@tellnes tellnes closed this as completed Mar 1, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants