committer guide: update rules for contrib software.

[eadler]

Summary

• 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

[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.

en_US.ISO8859-1/articles/committers-guide/article.xml

3506–3510

s/for when/when/

3512–3521

s/comitting/committing/

[seanc]

en_US.ISO8859-1/articles/committers-guide/article.xml

3515

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.

3524

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.

[eadler]

en_US.ISO8859-1/articles/committers-guide/article.xml

3524

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.

[eadler]

@seanc's feedback

[emaste]

Seems a good change overall, thank you

en_US.ISO8859-1/articles/committers-guide/article.xml

3506–3510

comma not needed

3507–3508

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

[eadler]

per @emaste

[rpokala]

en_US.ISO8859-1/articles/committers-guide/article.xml

3508

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

3521

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

3525

"maintainership email" => "maintainership, email"

[jhb]

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

[eadler]

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

[eadler]

oh. I already committed this in rD52130