path to restoring FreeBSD to Tier 2 support

[Trott]

What would have to happen to restore FreeBSD to Tier 2 support? Here's the tiniest of beginnings of a task list. Feel free to add to it. @nodejs/build

• Need a volunteer to do sys admin, troubleshooting, documentation, ansible-scripting, etc. for FreeBSD in CI. (If that person is an employee of a company invested in Node.js/FreeBSD, that would be a big plus, but not strictly a requirement.)

• ... what else?

[Trott]

Refs: nodejs/node#27383

[nschonni]

There is a public FreeBSD CI service now too https://forums.freebsd.org/threads/cirrus-ci-support-for-freebsd.68644/

[Trott]

Do we need to acquire one or more people to be the go-to FreeBSD experts when it comes time to create a release? I imagine that would be the Build WG member or members. I assume we don't need someone on the Release WG for that. But typing this out loud in case I'm wrong.

[Trott]

There is a public FreeBSD CI service now too https://forums.freebsd.org/threads/cirrus-ci-support-for-freebsd.68644/

Thanks! I do think we're going to continue to need FreeBSD in our existing CI. Public CI is not an option in a lot of situations for us, such as when we are doing security releases. And even if it were, I'm not sure fragmenting our CI across multiple services is a path to less maintenance pain instead of more (but I could be wrong!).

[Trott]

Putting on the meeting agenda even though I only opened it 15 minutes ago because:

• I believe this is worth talking about very publicly.
• This does not seem like the type of thing that warrants weeks of open-ended discussion. I believe if we had a 10-minute synchronous conversation, we could probably have the checklist completed. So let's just do that.

[refack]

IIUC the idea behind the downgrade is to "officially-unofficially" move freeBSD to the community-contrib path (#1788. Similar to Linux/ia32 and ARM6)

[refack]

• Need a volunteer to do sys admin...

I believe the other part is maintaining a robust @nodejs/platform-freebsd team to own the code side...

[targos]

• Need a volunteer to do sys admin...

I believe the other part is maintaining a robust @nodejs/platform-freebsd team to own the code side...

Yes! I think this comment explains a bit what our problem is regarding FreeBSD support: nodejs/node#27383 (comment)

If FreeBSD is a release-blocking platform, we have to fix any build issue in nodejs/node. It happened several times that a V8 upgrade was blocked only because of FreeBSD and we spent more time than necessary to fix the issues because no expert was here to help. Since issues had to be fixed by us in the first place, it might be why the FreeBSD port "just works".

[nomadlogic]

If FreeBSD is a release-blocking platform, we have to fix any build issue in nodejs/node. It happened several times that a V8 upgrade was blocked only because of FreeBSD and we spent more time than necessary to fix the issues because no expert was here to help. Since issues had to be fixed by us in the first place, it might be why the FreeBSD port "just works".

it sounds like a lot of this is due to lack of communication between teams. aside from being sure FreeBSD developers are subscribed to this and the main nodejs issue feeds, are there other less noisy ways to ensure problems like you mention do not get missed? personally speaking i'm sub'd to nodejs/build and nodejs/node projects on github (with some filtering to lower the signal/noise ratio), but are there other communication channels FreeBSD should also be keeping an eye on?

[refack]

but are there other communication channels FreeBSD should also be keeping an eye on?

We have the @nodejs/platform-freebsd team, but for $GITHUB_REASONS you need to be a members of the Org to subscribe to that team's notifications.

[sam-github]

I'd personally be OK with adding FreeBSD members as nodejs collaborators even if they don't have a nodejs contributions history, if that's what it takes for them to be get notified of issues, and start being contributors.

[rvagg]

On the infra side: it would be good to have some FreeBSD natives who are somewhat present around nodejs/build (casually following the repo and watching for ways to jump in) and in the nodejs/platform-freebsd team as well so we can use that to summon help where needed.

But we still have a problem with turn-around, @Trott this goes back to our discussion about urgency and downtime: there's one class of problem where there's just something that needs to be taken care of but is not super urgent (like FreeBSD machines not having an auto-restart mechanism for the Jenkins process which was a huge headache for the longest time until someone finally put monit on them). But then there's another class of problem where something's failing right now and someone has to fix it. That falls on those of us who are more present—who watch the repo, who are on IRC and who tend to get pinged when there are urgent matters (because we tend to be responsive: myself, Refael and Michael get that the most at the moment I think).

This second class is where the pain is felt and I don't think that can be solved by casual involvement. The reason FreeBSD was easy for us earlier on was because we had Johan who was a core Build member, was very active and available, he was also a FreeBSD native (which is why we still have things like the linter running on FreeBSD). Without a Johan around these urgent things fall on me and the other active members and this is where the biggest problem is.

Back to my comments on nodejs/node#27383: the experience for me of managing FreeBSD and picking up pieces when things fail (combined with a brief and disastrous run with FreeNAS at home), have made me really dislike FreeBSD. And it's my strong impression that its presence in our CI system is much more of negative than a positive for the work that we need to get done here. I feel almost exactly the same way about SmartOS to be honest but it gets more of a free pass because at least Joyent is a major infrastructure contributor (and Colin et. al. are usually responsive to calls via nodejs/platform-smartos).

Our infrastructure make-up is really driven very strongly by the individuals, and companies, that contribute here. It's not all about Node core needs, there's a big element of preferences. e.g. we have a ton of Ubuntu in our mix, it runs some our most important servers and it's the base OS for a lot of our Docker container work—that's almost entirely about my personal preferences, not necessarily technical merit. If Johan was still an active contributor then we'd probably see a much stronger presence of FreeBSD and Debian.

If you like FreeBSD, then there's a good chance you're a bit of a systems nerd and you might even enjoy the work we do around here across many systems. So maybe you should consider getting more involved and becoming one of those people that reacts to urgent needs. If we had that, and the core dev team didn't have the sense that FreeBSD gets in the way (as @targos pointed out above), then I'm sure it could easily raise in status.