Why I am retiring from contributing to FreeBSD

[franco]

I suppose you are right.  I can only give my outside perspective here.  There's definitely a structural issue at play here that makes inclusion and mutual respect wishes on a paper more than anything that is lived by.  I believe we can all agree on a technical patch that goes throw a review process.  FreeBSD has all the tools and interested people to do it.  The unspoken exercised culture, however, is one of lack of accountability and likely hard to overcome to be more goal oriented, open and collaborative.  Things that nobody else cares about are not tended to even if contributions exist.  This is where FreeBSD loses traction that would be an easy win.

Now at least some of my ports found no delay in maintainership which I find good and strange at the same time as if this behaviour fixes a structural problem the ports were having.  I hope that incentive lasts, yet ports already start falling behind with CVEs and upstream releases out in the wild.  Very happy that's not the case for our users, because there is an established process: test -> commit -> ship -> enjoy  :)


Cheers,
Franco

[trasz@]

So, FreeBSD core team hasn't bothered to release their monthly reports for half a year now.  Developers have no idea what's going on and core@ behaves as if they owned the place.  Questions regarding dch@'s (Dave Cottlehuber's) abuse of his position remain unanswered.

[Greg_E]

Eventually all the other devs will leave and back something else, or fork it again.

[trasz@]

Forking is a very bad scenario for the project and should be avoided at any cost.

Especially that there's really no reason to fork - there's nothing wrong with FreeBSD source or developer base.  It's a disagreement specifically about core@, which is supposed to be administration / "HR" more than anything.  They don't make technical decisions, they don't maintain the infrastructure.

[Patrick M. Hausen]

Plus the Foundation, e.g. most prominently Deb and Ed, are doing a very good job, IMHO.

[trasz@]

I worked for the Foundation for a while, so I'm biased... but yeah, they are :)

I wonder if we could "fork" the problematic bits alone - like the core@ and infrastructure they can control - and then let people at FreeBSD.org choose who they prefer to work with.  Especially given the current climate, and the fact that core@ has already been forced to comply U.S. shenanigans in the past.

[franco]

Reading more about the purpose of the core team I've never had the pleasure to deal with them for their main purpose of wrangling commit rights ever. I'll be honest that dch@ was dangling them in 2024 Dublin but it was rather clear this wasn't really happening so there was no mutual approach to this ever and someone else confirmed to me that he appeared to not tell me the truth back then. I fundamentally disagree to leadership styles I've witnessed. Programmers rarely make good managers. Managers also not always make good managers. The problem isn't managing commit bits. The problem starts when attempting to manage people on the matter of commit bits and coming down only on either side ever and no willingness to do better.

From what I've seen in over a decade pass by on Bugzilla and mailing lists... some people have commit bits for short, small commit histories and in one instance multiple core team members could/would not answer me how a particular src-only committer would appear to commit to ports as well, ignoring maintainer timeout procedure and adding port plist issues in that same process. Luckily that person stopped committing altogether, which made that person the oddest choice to begin with. Furthermore, committers would neglect contributions, engagement and not extend trust or expertise. A "who are you" directed at an external contributor is really a question of "don't you know who I am" and the process of contributing falls flat on its face as people set up their egos to fail in the technical discussions never to be responded again. But I digress.

The core team seemed to find some bite in recent years for auxiliary topics, but that's largely directed at easy victims to cement status quo and avoid addressing structural issues. To me it seems the whole concept of the team is becoming a problem in itself with re-cycling members and declining committer pool growth. I think the protectionism is a bit misplaced which in part is a human condition although that would still not justify keeping things as they are if FreeBSD wants to start a new growth phase. The work of the core team is not boiling down to a chain of "not everyone will always like what we do" decisions. If that's the internal MO then yes we're scraping the bottom of the barrel with governance and things should really change rather than go on like this.

Between core team and foundation there has always been a lack of entity that works on cooperation and motivation or general engagement with the user side. Some would call this a "community manager". Not that one is needed, but there's also lack of FreeBSD culture around that principle also in part due to said protectionism and strict enforcement of committer/user relationships and pushing away side projects as "being on their own". None of this helps users and release quality, but I'm sure the people who feel this is necessary know the implications, but would still not change anything because that's easier for them (to have a productive year without dealing with code of conduct complaints, huh).


Cheers,
Franco

[trasz@]

The way commit bits work is that an existing committer (anyone with FreeBSD.org email) sends core@ an email proposing someone, and then core votes on that.  I guess you could describe this at "dangling".  But the weird thing is - correct me if I'm wrong, but in late 2024 Dave was already a core team member, and voting on your own candidate feels kinda sus.  Also, core is not supposed to do leadership - the person who proposes you for commit bit becomes your mentor, core has nothing to do with that afterwards.

Regarding src folks committing to ports or vice versa - that's acceptable as long as you make sure you know what you're doing, eg get an "ok" from your mentor or a ports committer.  But you're supposed to still follow all the ports rules, like maintainer timeouts.

Wrt community manager - I think that would be the Foundation.  Not sure if it was established with that in mind, but that's large part of what they do.  They are also independent from core team.

As for the (rather depressing) rest - I agree, and from our internal mailing list this seems to be a fairly common view.

[chrcoluk]

I can offer my 5 pence on that long bug report conversation.  I apologise if anyone is offended by it.

First, my view is that the nature of the bug is pretty scary, we have had issues over the years with weird IPv6 behaviours, weird PF issues, which can be very frustrating for people operating misbehaving networks, if it also affected ICMP packet too big stuff, then it is especially nasty, and I think its clear regression testing is inadequate on FreeBSD. 
Second I can see the asks's to back out the original security patch, as a end user I definitely see the logic in the request, but I very rarely see developers back out code, they usually die on that hill.  I agree with dok's comment that the issues the patch was causing are far more serious than a vague low risk security bug. 
Third, I think the idea to use a vanilla FreeBSD kernel on OPNsense to get the bug moving again was sound and should have been done right away after it was suggested.  It doesnt matter if its felt it was wrong, just do it to satisfy all parties for democratic reasons. 
Fourth was some bickering which was not a good luck on anyone. 
Fifth the entire bug report makes FreeBSD look pretty bad in many areas, which its lask of regression testing as well as urgency in getting the issue fixed, even if it means backing out.

Is this still not properly fixed in FreeBSD upstream?

[meyergru]

At least we cannot be sure of that. From time to time we stumble upon another piece of the puzzle.

And for the record: This was a (small) security problem that had been fixed in the other BSD project and ported to FreeBSD, but only in parts (that seemed to matter). It was never clearly communicated which parts where fixed, because the fixes were done incrementally and augmented via several bug reports. Some of those were simply disregarded, because they were not reported on "pure" FreeBSD, but on OpnSense, laying the burden of proof on users.

So, to answer your question, you would have to take the initial fix and compare it across all over the place in FreeBSD. Would you like to volunteer?

All we know is that there were documented missing parts of specific ICMPv6 handling that were left out and led to the exact bug sighting that were to be expected from it, all sidelined with pure denial of these facts and pointing how this must be done - with each of the missing parts tracked down according to the FreeBSD process.

[chrcoluk]

Nope, cant volunteer, so basically it sounds like its still not clear if its properly resolved upstream, my view is, if it isnt regression tested, it shouldnt have been committed in the first place, which aligns with the view that Dok posted.

So another broken network path in FreeBSD potentially lasting several years and multi generations of release.  At least OPNsense has backed it out.

I do feel the decision all those years ago to keep the custom multi threaded PF over keeping up with OpenBSD PF has continued to hunt FreeBSD.  This situation is part of that fallout with picking specific patches from OpenBSD in the hope of fixing it on FreeBSD.  A Frankenstein PF.  I did mention this on reddit not that long ago and ironically the guy who responded to me quite angry is the same person making the commit's in that big report.  He really did not like me mentioning that.