-
Notifications
You must be signed in to change notification settings - Fork 30.3k
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
Comments
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. |
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. :) |
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. |
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.) |
/ping @nodejs/platform-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. |
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. |
@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!) |
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.) |
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. |
Hey @mhdawson adding you to this thread following our chat yesterday as things have progressed since then.
(Edit) I should add that I am happy to facilitate/attend meetings, document process and generally support these interactions. |
@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. |
Thanks @sam-github 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 |
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. |
Maybe this conversation can continue over in nodejs/build#1791? |
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.
The text was updated successfully, but these errors were encountered: