Dapr Graduation Due Diligence #1454
Conversation
Signed-off-by: Davanum Srinivas <[email protected]>
| - TAG Security recommends documenting [Security Self-Assessment](https://tag-security.cncf.io/community/assessments/guide/self-assessment/) | ||
| - TAG Security recommends a [joint assessment](https://github.com/cncf/tag-security/blob/main/community/assessments/guide/joint-assessment.md) as well building on the self-assessment above. The existing work already done in Dapr including the several audits and documentation of the [threat model](https://docs.dapr.io/concepts/security-concept/#threat-model) will come in handy. | ||
| - TAG Contributor Experience recommends adopting some tooling such as [clowarden](https://github.com/cncf/clowarden), [prow & peribolos](https://docs.prow.k8s.io/docs/components/cli-tools/peribolos/), [sheriff](https://github.com/electron/sheriff) or other tool that can manage org membership & permissions in a more transparent manner. | ||
| - TOC reviewers [recommend](https://github.com/dapr/community/pull/540/files) a better definition of a "sub-project" as counting each repo as a sub-project ends up with too many of them. Having a better aggregation will help create named roles like "technical leads" which sets up folks better for going up the contributor ladder. TOC reviewers especially worry about "bus factor", having the next rung of leadership mentored and ready will alleviate the situation. |
There was a problem hiding this comment.
In the past we've also guided projects on defining lifecycles for their sub-projects, particularly for sub-projects defined as "core" (packaged with the project) and ancillary (those not packaged or required for the main project to function). We've also suggested adding maturity in that lifecycle (alpha, stable, etc.)
Does Dapr's sub-project structure lend itself to those additional recommendations?
There was a problem hiding this comment.
The component certification lifecycle has been thoroughly documented here: https://docs.dapr.io/operations/components/certification-lifecycle/
The components are packaged with core in a release. Each team has a tracking issue that feeds into the Release Planning issue. Example: The components for v1.12 were tracked in this issue and included in the main Release Planning issue for v1.12. The component lifecycle is being adhered to and only packaged into core when move to stable, e.g. Zeebe command binding component moved to stable in v1.12 and was then included with the core build for the release.
| - [ ] **Roadmap change process is documented.** | ||
|
|
||
| There is no current roadmap change process documented. [Tracking issue #4377](https://github.com/dapr/docs/issues/4377) in the Dapr docs repo has been created to track Roadmap process improvements including creating and documenting a roadmap change process. |
There was a problem hiding this comment.
Has this been corrected? If so, do the tracking issue contain sufficient information that this Criteria is now met and no longer blocking?
There was a problem hiding this comment.
Updated with latest commit - the roadmap change process has been sufficiently documented to meet this Graduation requirement.
| - [ ] Tagging as stable, unstable, and security related releases | ||
|
|
||
| Releases aren't specifically tagged as stable, unstable or security. They are [tagged](https://github.com/dapr/dapr/tags) as either a stable release or a "Release Candidate", which is inherently unstable as it is still undergoing testing prior to stable release. | ||
|
|
||
| However, a tracking issue may be specified as a security release in the tracking issue for the Minor release, but not tagged as such. | ||
|
|
||
| Bug fixes are included in both Release Candidates and Stable releases. They can be included in a major or minor release alongside other features, or solely in a minor release and are documented thoroughly. Example: [Dapr 1.14.4 release](https://github.com/dapr/dapr/releases/tag/v1.14.4). | ||
|
|
||
| [Issue #8188 in the Dapr repo](https://github.com/dapr/dapr/issues/8188) has been created to track tagging policy clarification. | ||
|
|
There was a problem hiding this comment.
Has this been met with the current tagging process in place or is this expected to be met upon completion of Dapr 8188?
Reading the evaluation it appears that they partially meet the requirement in a manner that is sufficient to be deemed non-blocking. Particularly with the issues filed.
There was a problem hiding this comment.
This has been partially met in a manner sufficient to be non-blocking. Though, the recommendation is to follow these recommendations for release and management best practices. Will update the DD to mark this as completed and clarify.
There was a problem hiding this comment.
Updated with latest commit.
| - [ ] Information on branch and tag strategies | ||
|
|
||
| The Dapr project provides information on branch strategies in the [Maintainer guide](https://docs.dapr.io/contributing/docs-contrib/maintainer-guide/). | ||
|
|
||
| The project does not currently provide information on tag strategies. [Issue #8188 in the Dapr repo](https://github.com/dapr/dapr/issues/8188) has been created to track adding tag strategies to the Dapr process documentation. |
There was a problem hiding this comment.
Is there information sufficient to mark this as met? Our criteria is listed as an "and", however the issue opened may be sufficient to mark this resolved.
There was a problem hiding this comment.
Yes, this can be marked as resolved - the tag strategies are a non-blocker yet recommended to be completed soon after Graduation. Will update to resolve and clarify.
There was a problem hiding this comment.
Updated with latest commit.
Co-authored-by: Emily Fox <[email protected]> Signed-off-by: Karena Angell <[email protected]>
Signed-off-by: Davanum Srinivas <[email protected]>
Co-authored-by: Emily Fox <[email protected]> Signed-off-by: Davanum Srinivas <[email protected]>
- rename from cert-manager-graduation.md to dapr-graduation-due-diligence.md - include feedback from @TheFoxAtWork; - resolve outstanding blockers
This PR contains the due diligence for Dapr application to move to graduated status.
Project application issue: #1354
Overall the project fulfills all the necessary criteria to move to the next level. Very happy with the level of responsiveness of Dapr folks to work with us for the extensive review. Many thanks.
NOTE: Currently this PR has been opened for Internal TOC Review, once that is done, we will open it up for Public Review!