Page MenuHomeFreeBSD

committer guide: update rules for contrib software.

Authored by eadler on Jul 2 2018, 1:57 AM.
Referenced Files
Unknown Object (File)
Mon, Nov 27, 7:53 AM
Unknown Object (File)
Wed, Nov 22, 8:16 PM
Unknown Object (File)
Sun, Nov 12, 1:55 AM
Unknown Object (File)
Thu, Nov 9, 10:45 PM
Unknown Object (File)
Mon, Nov 6, 5:50 AM
Unknown Object (File)
Sun, Nov 5, 10:56 AM
Unknown Object (File)
Tue, Oct 31, 3:42 PM
Unknown Object (File)
Oct 31 2023, 1:59 PM


Group Reviewers
Core Team
  • Most notably don't require talking to core@ to take on maintainership.
  • Merge an FAQ into the main body of the text
  • Wordsmith
  • Remove references to CVS

Diff Detail

No Lint Coverage
No Test Coverage
Build Status
Buildable 18365
Build 18081: arc lint + arc unit

Event Timeline

jhb added a subscriber: jhb.

I would also add a bullet in the commit log to say "Remove comments specific to CVS". Taking files off of the vendor branch and some of the other language was CVS specific and it's good that you are removing it.

I'd be tempted to also add a requirement to use the vendor import process when committing to those areas (since we've had a few commits recently that didn't do real merges), but I don't think we really need that right now.


s/for when/when/



This revision is now accepted and ready to land.Jul 2 2018, 5:52 PM

Can we strengthen the language here slightly? Something like:

contrib/ software is home to various forks of upstream software that the FreeBSD Project has agreed to maintain locally. The reasons for maintaining a fork ranges from wanting strict control over a tightly coupled dependency to lack of portability or trust in the canonical repository's distribution of their code. Regardless of the reason(s), effort to minimize the maintenance burden of fork is helpful to fellow maintainers.


you're encourage to take up ownership (or reevaluate whether or not we need to maintain our own independent fork and can possibly get by with a ports-managed) distribution of the contributed software.

If we don't have a maintainer for something it's also worth providing a small hint that we can also reexamine whether or not we want the code in contrib/ at all. This advice isn't limited to contrib/ but bears repetition because our forks are always inherently out of date with the canonical upstream repository.


I'd rather not add this. It leads to the "What should be in base" debate. Unless and until we have a meaningful standard for that, this will just result in bikesheds.

This revision now requires review to proceed.Jul 26 2018, 5:31 AM

Seems a good change overall, thank you


comma not needed


I might write "As a general rule" instead of "Strongly consider"

rpokala added inline comments.

"general consider" => "general rule, consider"


"every import." => "as part of every import." or "after every import."


"maintainership email" => "maintainership, email"

Ping? Ravi's comments are good, but i think with those changes this should be committed.

I'll commit this now. I've been busy with other things.

oh. I already committed this in rD52130