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

FreeBSD Support Deprecated to Experimental #27383

Closed
No9 opened this issue Apr 24, 2019 · 16 comments
Closed

FreeBSD Support Deprecated to Experimental #27383

No9 opened this issue Apr 24, 2019 · 16 comments
Labels
freebsd Issues and PRs related to the FreeBSD platform.

Comments

@No9
Copy link
Member

No9 commented Apr 24, 2019

Hey @rvagg

I see you merged a change into BUILDING.md that moved FreeBSD to experimental support
b581d59#diff-396d0b75211f5646b2fa730fbdf80a40R114

The last time I saw this discussed the decision was to leave it at level 2 support following a bolstering of the @nodejs/platform-freebsd with committers from the FreeBSD community.
#14499 (comment)
It may have been discussed else where since but my github search foo isn't finding anything right now.

I notice that there has been an update to the wording of Tier 2 support to state that Test failures on tier 2 platforms will block releases.
b581d59#diff-396d0b75211f5646b2fa730fbdf80a40R72

So I understand the reasoning behind demotion but as stated in #14499 experimental does not reflect the support FreeBSD has and it does send the wrong message for those who work on the platform.

Do you think the creation of a Tier 3 with the same wording as Tier 2 but without Test failures on tier 2 platforms will block releases. has any merit?
If so what would be the best way to land that into the docs.

Thanks for any help you can give or if you know who else I should pester then please let me know.

@rvagg
Copy link
Member

rvagg commented Apr 24, 2019

Hey @No9, the answer is simple: we have zero people on @nodejs/build currently who specialise in FreeBSD. FreeBSD is a pain in the neck for the rest of us to maintain and they're less reliable than most of our Linux infra (they've annoyed me personally enough over the years that I wouldn't be sad to see it all gone). Because Build is in the process of trying to rationalise our stretched resources we have to trim fat and moving platforms to Experimental is a way of decreasing the burden. Additional tiers likely isn't on the cards as then we'd probably have more tiers than people to manage them!

It's over in https://github.com/nodejs/build that any change would take place on this front and that would happen with membership on @nodejs/build of active people willing to take responsibility for FreeBSD.

@rvagg rvagg closed this as completed Apr 24, 2019
@lattera
Copy link

lattera commented Apr 24, 2019

Hey @rvagg, thank you very much for your explanation. You mention that FreeBSD is a pain in the neck to maintain. I'm curious if you could expound on that. Perhaps we can change what you feel is painful. :)

@nomadlogic
Copy link

Just to second @lattera - even if there are old bugs or mailing list threads where this frustration is born out of it would be helpful for us get better context for those of us who support node environments and want/need to improve things.

@Trott
Copy link
Member

Trott commented Apr 24, 2019

Hey @rvagg, thank you very much for your explanation. You mention that FreeBSD is a pain in the neck to maintain. I'm curious if you could expound on that. Perhaps we can change what you feel is painful. :)

I can't speak for @rvagg, but since I'm technically on the Build WG too and I certainly have run into issues and have my own opinions: I interpreted the "pain in the neck" comment to mostly mean that the people on Build WG are not regular users of FreeBSD so when a problem arises, they have very little knowledge and experience to draw on. I didn't interpret it as a statement about FreeBSD inherently being a "pain in the neck", but I certainly see how that is a logical straightforward reading of the comment, especially given the "less reliable" comment. And again, this is my opinion only. @rvagg may or may not have meant something closer to a criticism of FreeBSD itself. Only he can say, of course.

(I don't think FreeBSD is inherently less reliable, but since we don't have the expertise to set up FreeBSD in a robust fashion, problems are simply more likely to arise more often on FreeBSD than elsewhere for us. Again, my opinion only.)

I would absolutely love for one or more people with a lot of FreeBSD expertise and some sys admin and/or cloud administration experience to join Build WG. And I would love for companies invested in FreeBSD to step up to help us out too. (Not saying they don't already. Digital Ocean and possibly others provide infrastructure, etc. But more help is welcome.)

@Trott
Copy link
Member

Trott commented Apr 24, 2019

/ping @nodejs/platform-freebsd

@Trott Trott added the freebsd Issues and PRs related to the FreeBSD platform. label Apr 24, 2019
@sam-github
Copy link
Contributor

that would happen with membership on @nodejs/build of active people willing to take responsibility for FreeBSD.

I suggest this is the most actionable statement. If there are people sufficiently interested in FreeBSD to join the build WG, please open an issue and ask to join. If I understand correctly, no FreeBSD advocate is currently a member of the build WG.

Its not a question of quality of O/S, its that when a new build comes around and someone has to update the ansible configs to get new compilers on FreeBSD, etc, its nice if there are people around who actually use FreeBSD. I've been doing RedHat derived distro maintenance recently, and while I'm sure yum is a fine tool, I've been using Debian distros for 20 years, its totally unfamiliar to me, and I spend a lot of time googling yum error messages.

@nomadlogic
Copy link

thanks for the comments @Trott and @sam-github.

From my experience I generally follow the FreeBSD porters work for node, and use our projects bug tracker to report any issues that pop up, so this may explain why there aren't a ton of FreeBSD users on this list - the port pretty much "just works".

But it sounds like this is a good opportunity to get myself more involved in the development process of node itself, as such I'm now subscribed to the bug report feed here. Hopefully some others will also be motivated to do so as well and we can help get the build infrastructure in a better place, or at the least help quickly triage issues issues when they do happen.

@emaste
Copy link

emaste commented Apr 25, 2019

@Trott are there some docs or notes on the required tasks or workload of build WG members?

@Trott
Copy link
Member

Trott commented Apr 25, 2019

@Trott are there some docs or notes on the required tasks or workload of build WG members?

AFAIK, we don't have anything formal and structured along those lines. (Pull requests welcome!) But to get started, here are some things I'd recommend trying. It is not necessary to do all of these. They're just ideas that come to mind right now.

If you think you're ready to help out (and some people may be ready to help out without doing very much of the above, while others may want to steep themselves in this stuff for a bit--everyone is different), open an issue in the Build repo saying that you'd like to help, what it is you can offer in terms of time and/or skills and/or resources, optionally suggest specific things you'd like to do, and ask what's next. You'll probably be invited to attend meetings as an observer, which may sound dull, but the personal interactions that happen there are likely to be where the rubber hits the road so to speak.

Hope this helps. Sorry it's kind of an information dump rather than an organized process. (Organizing our processes is definitely something the Build WG could use some help with!)

@Trott
Copy link
Member

Trott commented Apr 25, 2019

the required tasks or workload of build WG members?

Actually, looking more closely, I answered the question I hoped you were asking ("how do I get involved?") and not the question you did ask. So let me try again:

There are no workload expectations or required tasks. People are expected to do something. Inactive people eventually get removed from the WG (because they often have access privileges that make inactivity a liability). But there is no minimum cut-off that I'm aware of. And the activity varies greatly. I think it's fair to say that @refack and @rvagg are vastly more active than I am, for example. I do a lot of talking/commenting, but they do a lot of actual Getting Stuff Done. (My value is largely as a heavy user of CI. So I report a lot of problems and can often spot patterns or know how to recreate problems that occur only intermittently. I also do simple sys admin activities to fix hosts when stuff breaks. But the word "simple" in that sentence is key. This is a long-winded way of saying that there are a lot of different possible roles for members.)

@emaste
Copy link

emaste commented Apr 25, 2019

I answered the question I hoped you were asking ("how do I get involved?") and not the question you did ask.

Thanks for the clarification; I should have asked "what are the expectations and workload, and how do any of us with an interest in FreeBSD support start getting involved?" So the dual-part answer is much appreciated.

@No9
Copy link
Member Author

No9 commented Apr 25, 2019

Hey @mhdawson adding you to this thread following our chat yesterday as things have progressed since then.
Could you help @emaste with his question?

"what are the expectations and workload, and how do any of us with an interest in FreeBSD support start getting involved?"

(Edit) I should add that I am happy to facilitate/attend meetings, document process and generally support these interactions.

@sam-github
Copy link
Contributor

I generally follow the FreeBSD porters work for node, and use our projects bug tracker to report any issues that pop up, so this may explain why there aren't a ton of FreeBSD users on this list - the port pretty much "just works"

@nomadlogic That will find actual node bugs specific to FreeBSD, which are fairly rare from what I recall, so I can see that from that perspective FreeBSD might appear to be doing quite well. Over here in build, the FreeBSD support effort isn't about problems with the actual code, its about maintaining the build infrastructure.

@No9 I think @Trott answered your question just above

@sam-github sam-github changed the title FreeBSD Support Depricated to Experimental FreeBSD Support Deprecated to Experimental Apr 25, 2019
@No9
Copy link
Member Author

No9 commented Apr 25, 2019

Thanks @sam-github
I did see the response from @Trott but I should have added more colour to my ask.

Really I am trying to understand how we take the suggestions from everyone and put something more structured in place so it's clear to everyone what needs to be done to get FreeBSD back to Tier 2.

I think we have a very good shape on the areas that need looking into but more specifics would be good and also help set expectations.

As suggested I'll join the build calls and see how we can move this forward

@sporkman
Copy link

I don't want to overextend myself with volunteer opportunities, but I'd be willing to commit some small amount of time to basic sysadmin tasks. I have zero experience with Jenkins, but if the main issue is just keeping the DO instances up to date, running, and monitored, I can assist with a few hours/month there.

@Trott
Copy link
Member

Trott commented Apr 25, 2019

Maybe this conversation can continue over in nodejs/build#1791?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
freebsd Issues and PRs related to the FreeBSD platform.
Projects
None yet
Development

No branches or pull requests

8 participants