Update due-diligence-guidelines.md to be explicit about dependencies #509
Conversation
Be explicit about collecting dependencies and listing them
|
@lizrice @quinton-hoole @erinaboyd - making a short addition to the DD guidelines to make documenting dependencies an explicit requirement |
| @@ -82,7 +82,7 @@ the detail where necessary. | |||
| * What are the most important holes? No High-Availability? No flow control? Inadequate integration points? | |||
| * Code quality. Does it look good, bad or mediocre to you (based on a spot review). How thorough are the code reviews? Substance over form. | |||
| Are there explicit coding guidelines for the project? | |||
| * Dependencies. What external dependencies exist, do they seem justified? | |||
| * Dependencies. What external dependencies exist, do they seem justified? Note: all core dependencies should be listed in the document along with the details of relevant repos | |||
There was a problem hiding this comment.
yes - that was the intent - happy to change it if there is better wording.
There was a problem hiding this comment.
"non-optional" seems better otherwise folks will debate what "core" is/means :)
There was a problem hiding this comment.
I don't know how to get the terminology right here but I think we need to distinguish between significant functional dependences, and programming language / package dependencies. We don't want to be reviewing giant lists of, say, Go packages or Node dependencies, but we do want to know when a project assumes the existence of a significant external component.
There was a problem hiding this comment.
The scenario we are trying to address is as follows: a project is made up of multiple repos, and all the repos are required for core functionality (i.e. this means "non-optional", but also core as in "project core", not 3rd party dependencies) - we want to be able to capture the full list, and make sure the project is viable with the list of submitted repos.
We should not need to list repos for external dependencies (e.g. etcd for K8s) or programming/package dependencies (e.g. standard available libraries).
how about: "Note: the document should list all non-optional project repos that are required for core functionality and production deployment"
|
@chira001 do we want to add another list item about cross checking licenses for all dependencies and make a list of things that do are not white listed here? https://github.com/cncf/foundation/blob/master/allowed-third-party-license-policy.md ( this is a slightly different problem then the original above ) |
I think this is already covered by "Does it have a license? Which one? Does it have a CLA or DCO? Are the licenses of it's dependencies compatible with their usage and CNCF policies? CNCF staff will handle the full legal due diligence." and the graduation policy already specifies that the project needs to comply with the CNCF IP Policy, but you are right - it would be helpful to include a reference in the guidelines. |
|
@erinaboyd we already have a list :) https://github.com/cncf/foundation/blob/master/allowed-third-party-license-policy.md |
Be explicit about collecting dependencies and listing them