Messages

So, there's a (minor) update: after I've submitted a formal CoC violation report against David Cottlehuber <dch@FreeBSD.org>, the old (soon to be replaced, elections in progress) core@ now claims that CoC is actually a terrible idea and we shouldn't be enforcing it xD

Not sure if it will void their previous "findings", like banning you.

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.

The argument it should be set to 0 in production releases is sound though.  I wonder if you could file a FreeBSD PR to suggest that change, probably by adding KDB_UNATTENDED when branching a release, bit like we do with MALLOC_PRODUCTION?

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.

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.

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.

I fully agree that CoC cannot be applied selectively; it's just that from what I've seen, it's not much better when you're a committer.  Core ignored my own report couple of months ago, and I've seen two mentions of other cases like this - all from people with commit bits.

At the same time, it absolutely can be a problem to reply to an email; look up "executive dysfunction".  But there's like a half dozen people on core@, and a single one would be enough to move it forward, so I don't think that's the likely cause here.

I'm not sure it's a problem with CoC, or if it's being use by core@ as an excuse for their arbitrary decisions.  In my case last summer, core first determined that I hadn't violated CoC (acc to Gleb's writeup), and then proceeded to straight out lie to me about it.

FWIW, core team is not responding to emails from FreeBSD committers anymore either.  They know they screwed up badly by trying to kick me out at request of certain youtuber, then were forced to (partially) confess to developers@.  I guess they have learned they can just ignore the developer community.