Document Source Management Team policies
Needs ReviewPublic
Actions

Authored by imp on Sat, Oct 10, 7:57 PM.

Details

Reviewers: None

Summary

Fill previously empty srcmgr/policies.adoc placeholder with actual
policies documented from srcmgr practice: code review expectations,
compilation requirements, testing expectations, main branch soak
time, commit access principles, bit reclamation timeline, and stable
branch rules.

Update srcmgr/_index.adoc to reflect policies are now complete.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

Diff Detail

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 77979
Build 74862: arc lint + arc unit

Event Timeline

imp requested review of this revision.Sat, Oct 10, 7:57 PM

imp created this revision.

Harbormaster completed remote builds in B77979: Diff 189408.Sat, Oct 10, 7:57 PM

imp added a parent revision: D60596: Add mission/vision/values and governance model documents.Sat, Oct 10, 7:57 PM

imp added a child revision: D60598: Reorganize Ports Management Team policies for clarity.

emaste added a subscriber: emaste.Sun, Oct 11, 3:25 PM

emaste added inline comments.

website/content/en/srcmgr/policies.adoc
14	"Pre-commit code review"?
18	We have a discussion of phab vs github in CONTRIBUTING.md as well. I think listing these as preferred/acceptable makes sense here, but we might want to revisit CONTRIBUTING and clarify it a bit. My take is: Use Phabricator if any of the following are true: you are a FreeBSD committer you're working closely with one or more FreeBSD committers on some body of work (i.e., you know who is going to land the change) the change is large or controversial Use GitHub if both are true: you already have a GitHub account (and probably not a Phabricator account) the change is straightforward
44	We haven't really codified this before?
53

Thanks for the review ed! Much appreciated.

website/content/en/srcmgr/policies.adoc
14	Yes. That's a stronger, and better, statement.
18	I'll bring this in. There's one other time, though, and that's to test with github's CI. Is that too much detail?
44	It's in the cross repo policy I just did. I wasn't sure if we needed it here or not. Some of this work is organizational vs writing stuff down we do, but haven't documented.
53	better framing! Thanks!