Page MenuHomeFreeBSD

committer guide: update rules for contrib software.
AbandonedPublic

Authored by eadler on Jul 2 2018, 1:57 AM.

Details

Reviewers
jhb
Group Reviewers
Core Team
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

Diff Detail

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

Event Timeline

eadler created this revision.Jul 2 2018, 1:57 AM
seanc added a subscriber: seanc.Jul 2 2018, 2:52 AM
jhb accepted this revision.Jul 2 2018, 5:52 PM
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.

en_US.ISO8859-1/articles/committers-guide/article.xml
3506–3510

s/for when/when/

3512–3521

s/comitting/committing/

This revision is now accepted and ready to land.Jul 2 2018, 5:52 PM
seanc added inline comments.Jul 9 2018, 1:53 AM
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 edited the summary of this revision. (Show Details)Jul 26 2018, 5:24 AM
eadler added inline comments.Jul 26 2018, 5:30 AM
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 updated this revision to Diff 45857.Jul 26 2018, 5:31 AM

@seanc's feedback

This revision now requires review to proceed.Jul 26 2018, 5:31 AM
emaste added a subscriber: emaste.Jul 26 2018, 3:02 PM

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 marked 7 inline comments as done.Jul 27 2018, 1:57 AM
rpokala added a subscriber: rpokala.Oct 4 2018, 9:57 PM
rpokala added inline comments.
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 added a comment.Nov 13 2018, 7:00 PM

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.

eadler abandoned this revision.Nov 15 2018, 4:13 AM

oh. I already committed this in rD52130