dragonflyoss
/
dragonfly
mirror of https://github.com/dragonflyoss/dragonfly.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Consolidate community docs (#4087) 

* docs: consolidate CODE_OF_CONDUCT.md

Let's refer to the community repo one.

Signed-off-by: Peng Tao <bergwolf@hyper.sh>

* docs: consolidate CONTRIBUTING.md

Let's refer to the community repo one.

Signed-off-by: Peng Tao <bergwolf@hyper.sh>

* docs: consolidate GOVERNANCE.md

Let's refer to the community repo one.

Signed-off-by: Peng Tao <bergwolf@hyper.sh>

* docs: consolidate SECURITY.md

Let's use the community repo one.

Signed-off-by: Peng Tao <bergwolf@hyper.sh>

* readme: update contributing and code conduct links

Point to the community repo ones.

Signed-off-by: Peng Tao <bergwolf@hyper.sh>

---------

Signed-off-by: Peng Tao <bergwolf@hyper.sh>
This commit is contained in:
Peng Tao 2025-05-23 15:59:40 +08:00 committed by GitHub
parent 322f9c1618
commit ebffa8917a
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
5 changed files with 7 additions and 637 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
CODE_OF_CONDUCT.md
View File

@ -1,76 +1,3 @@
# Contributor Covenant Code of Conduct # Dragonfly Community Code of Conduct
## Our Pledge Please refer to the [community code of conduct](https://github.com/dragonflyoss/community/blob/master/CODE_OF_CONDUCT.md).
In the interest of fostering an open and welcoming environment,
we as contributors and maintainers pledge to
make participation in our project and
our community a harassment-free experience for everyone,
regardless of age, body size,
disability, ethnicity, gender identity and expression,
level of experience, nationality,
personal appearance, race, religion,
or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment include:
- Using welcoming and inclusive language
- Being respectful of differing viewpoints and experiences
- Gracefully accepting constructive criticism
- Focusing on what is best for the community
- Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
- The use of sexualized language or imagery and unwelcome sexual attention or advances
- Trolling, insulting/derogatory comments, and personal or political attacks
- Public or private harassment
- Publishing others' private information,
such as a physical or electronic address, without explicit permission
- Other conduct which could reasonably be considered inappropriate in
a professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of
acceptable behavior and are expected to take appropriate and
fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove,
edit, or reject comments, commits, code, wiki edits, issues,
and other contributions that are not aligned to this Code of Conduct,
or to ban temporarily or permanently any contributor for
other behaviors that they deem inappropriate, threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public
spaces when an individual is representing the project or its community.
Examples of representing a project or community include using an official
project e-mail address, posting via an official social media account,
or acting as an appointed representative at an online or offline event.
Representation of a project may be further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable
behavior may be reported by contacting the project team at
<dragonfly-maintainers@googlegroups.com>. The project team will review
and investigate all complaints, and will respond in a way
that it deems appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an incident.
Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of
Conduct in good faith may face temporary or permanent repercussions as
determined by other members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 1.4, available at [https://www.contributor-covenant.org/version/2/0/][version]
[homepage]: https://contributor-covenant.org
[version]: https://www.contributor-covenant.org/version/2/0/

323
CONTRIBUTING.md
View File

@ -1,324 +1,3 @@
# Contributing to Dragonfly # Contributing to Dragonfly
It is warmly welcomed if you have the interest to hack on Dragonfly. Please refer to the [community contributing guide](https://github.com/dragonflyoss/community/blob/master/CONTRIBUTING.md).
First, we encourage this kind of willingness very much.
And here is a list of contributing guide for you.
## Topics
- [Reporting security issues](#reporting-security-issues)
- [Reporting general issues](#reporting-general-issues)
- [Code and doc contribution](#code-and-doc-contribution)
- [Engage to help anything](#engage-to-help-anything)
- [Join Dragonfly as a member](#join-dragonfly-as-a-member)
## Reporting security issues
Security issues are always treated seriously.
As our usual principle, we discourage anyone to spread security issues.
If you find a security issue of Dragonfly, please do not discuss it in
public and even do not open a public issue.
Instead, we encourage you to send us a private email to
[dragonfly-developers@googlegroups.com](mailto:dragonfly-developers@googlegroups.com) to report this.
## Reporting general issues
To be honest, we regard every user of Dragonfly as a very kind contributor.
After experiencing Dragonfly, you may have some feedback for the project.
Then feel free to open an issue via
[NEW ISSUE](https://github.com/dragonflyoss/dragonfly/issues/new).
Since we collaborate project Dragonfly in a distributed way,
we appreciate **WELL-WRITTEN**, **DETAILED**, **EXPLICIT** issue reports.
To make the communication more efficient, we wish everyone could
search if your issue is an existing one in the searching list.
If you find it existing, please add your details in comments
under the existing issue instead of opening a brand new one.
To make the issue details as standard as possible,
we setup an [ISSUE TEMPLATE](./.github/ISSUE_TEMPLATE) for issue reporters.
You can find three kinds of issue templates there: question,
bug report and feature request. Please **BE SURE** to follow
the instructions to fill fields in template.
There are a lot of cases when you could open an issue:
- bug report
- feature request
- performance issues
- feature proposal
- feature design
- help wanted
- doc incomplete
- test improvement
- any questions on project
- and so on
Also, we must remind that when filing a new issue,
please remember to remove the sensitive data from your post.
Sensitive data could be password, secret key,
network locations, private business data and so on.
## Code and doc contribution
Every action to make project Dragonfly better is encouraged.
On GitHub, every improvement for Dragonfly could be
via a PR (short for pull request).
- If you find a typo, try to fix it!
- If you find a bug, try to fix it!
- If you find some redundant codes, try to remove them!
- If you find some test cases missing, try to add them!
- If you could enhance a feature, please **DO NOT** hesitate!
- If you find code implicit, try to add comments to make it clear!
- If you find code ugly, try to refactor that!
- If you can help to improve documents, it could not be better!
- If you find document incorrect, just do it and fix that!
- ...
Actually, it is impossible to list them completely.
Just remember one principle:
> WE ARE LOOKING FORWARD TO ANY PR FROM YOU.
Since you are ready to improve Dragonfly with a PR,
we suggest you could take a look at the PR rules here.
- [Workspace Preparation](#workspace-preparation)
- [Branch Definition](#branch-definition)
- [Commit Rules](#commit-rules)
- [PR Description](#pr-description)
- [Developing Environment](#developing-environment)
- [Golang Dependency Management](#golang-dependency-management)
### Workspace Preparation
To put forward a PR, we assume you have registered
a GitHub ID. Then you could finish
the preparation in the following steps:
1. **FORK** Dragonfly to your repository.
To make this work, you just need to click the button Fork
in right-left of [dragonflyoss/dragonfly](https://github.com/dragonflyoss/dragonfly)
main page. Then you will end up with your repository in
`https://github.com/<your-username>/Dragonfly`,
in which `your-username` is your GitHub username.
1. **CLONE** your own repository to develop locally.
Use `git clone https://github.com/<your-username>/dragonfly.git`
to clone repository to your local machine.
Then you can create new branches to finish the change you wish to make.
1. **Set Remote** upstream to be
`https://github.com/dragonflyoss/dragonfly.git`
using the following two commands:
```bash
git remote add upstream https://github.com/dragonflyoss/dragonfly.git
git remote set-url --push upstream no-pushing
```
With this remote setting, you can check your git remote configuration like this:
```bash
$ git remote -v
origin https://github.com/<your-username>/dragonfly.git (fetch)
origin https://github.com/<your-username>/dragonfly.git (push)
upstream https://github.com/dragonflyoss/dragonfly.git (fetch)
upstream no-pushing (push)
```
Adding this, we can easily synchronize local branches with upstream branches.
1. **Create a branch** to add a new feature or fix issues
Update local working directory:
```bash
cd dragonfly
git fetch upstream
git checkout main
git rebase upstream/main
```
Create a new branch:
```bash
git checkout -b <new-branch>
```
Make any change on the `new-branch` then build and test your codes.
### Branch Definition
Right now we assume every contribution via pull
request is for [branch main](https://github.com/dragonflyoss/dragonfly/tree/main)
in Dragonfly. Before contributing,
be aware of branch definition would help a lot.
As a contributor, keep in mind again that every
contribution via pull request is for branch main.
While in project Dragonfly, there are several other branches,
we generally call them rc branches, release branches and backport branches.
Before officially releasing a version,
we will checkout a rc(release candidate) branch.
In this branch, we will test more than branch main.
When officially releasing a version,
there will be a release branch before tagging.
After tagging, we will delete the release branch.
When backporting some fixes to existing released version,
we will checkout backport branches. After backporting,
the backporting effects will be in PATCH number in
MAJOR.MINOR.PATCH of [SemVer](http://semver.org/).
### Commit Rules
Actually in Dragonfly, we take two rules seriously when committing:
- [Commit Message](#commit-message)
- [Commit Content](#commit-content)
#### Commit Message
Commit message could help reviewers better understand
what the purpose of submitted PR is.
It could help accelerate the code review procedure as well.
We encourage contributors to use **EXPLICIT** commit
message rather than an ambiguous message. In general,
we advocate the following commit message type:
- feat: xxxx.For example, "feat: make result show in sorted order".
- fix: xxxx. For example, "fix: fix panic when input nil parameter".
- docs: xxxx. For example, "docs: add docs about storage installation".
- style: xxxx. For example, "style: format the code style of Constants.java".
- refactor: xxxx. For example, "refactor: simplify to make codes more readable".
- test: xxx. For example, "test: add unit test case for func InsertIntoArray".
- chore: xxx. For example, "chore: integrate travis-ci".
It's the type of maintenance change.
On the other side, we discourage contributors
from committing messages in the following ways:
- ~~fix bug~~
- ~~update~~
- ~~add doc~~
#### Commit Content
Commit content represents all content changes
included in one commit. We had better include things
in one single commit which could support reviewer's complete
review without any other commits' help. In another word,
contents in one single commit can pass the CI to avoid code mess.
In brief, there are two minor rules for us to keep in mind:
- avoid very large change in a commit.
- complete and reviewable for each commit.
No matter what the commit message, or commit content is,
we do take more emphasis on code review.
### PR Description
PR is the only way to make change to Dragonfly project files.
To help reviewers better get your purpose,
PR description could not be too detailed.
We encourage contributors to follow the
[PR template](./.github/PULL_REQUEST_TEMPLATE.md) to finish the pull request.
### Developing Environment
As a contributor, if you want to make any contribution to
Dragonfly project, we should reach an agreement on
the version of tools used in the development environment.
Here are some dependents with specific version:
- golang: v1.15
- misspell: latest
- shellCheck: latest
- docker: latest
When you develop the Dragonfly project in the local environment,
you should use subcommands of Makefile to help yourself
to check and build the latest version of Dragonfly.
For the convenience of developers,
we use docker to build Dragonfly.
It can reduce problems of the developing environment.
### Golang Dependency Management
The Dragonfly project uses
[Go modules](https://golang.org/cmd/go/#hdr-Modules__module_versions__and_more)
to manage dependencies on external packages.
This requires a working Go environment with version 1.15 or greater installed.
To add or update a new dependency, use the `go get` command:
```bash
# Pick the latest tagged release.
go get example.com/some/module/pkg
# Pick a specific version.
go get example.com/some/module/pkg@vX.Y.Z
```
Tidy up the `go.mod` and `go.sum` files:
```bash
go mod tidy
```
You have to commit the changes to `go.mod`,
`go.sum` before submitting the pull request.
```bash
git add go.mod go.sum
git commit
```
## Engage to help anything
We choose GitHub as the primary place for Dragonfly to
collaborate. So the latest updates of Dragonfly are always here.
Although contributions via PR is an explicit way to help,
we still call for any other ways.
- Reply to others' issues if you could.
- Help solve other users' problems.
- Help review others' PR design.
- Help review others' codes in PR.
- Discuss Dragonfly to make things clearer.
- Advocate Dragonfly technology beyond GitHub.
- Write blogs on Dragonfly and so on.
In a word, **ANY HELP IS CONTRIBUTION.**
## Join Dragonfly as a member
It is also welcomed to join Dragonfly team if you are
willing to participate in Dragonfly community continuously and be active.
### Requirements
- Have read the [Contributing to Dragonfly](CONTRIBUTING.md) carefully.
- Have read the [Contributor Covenant Code of Conduct](CODE_OF_CONDUCT.md).
- Ability to maintain one or more modules of `scheduler`, `dfdaemon` and `manager`.
- Have submitted multi PRs to the community.
- Be active in the community, may including but not limited:
- Submitting or commenting on issues.
- Contributing PRs to the community.
- Reviewing PRs in the community.
### How to do it
You can do it in either of two ways:
- Submit a PR in the
[dragonflyoss/dragonfly](https://github.com/dragonflyoss/dragonfly) repo.
- Contact with the community's [maintainers](MAINTAINERS.md) offline.

189
GOVERNANCE.md
View File

@ -1,190 +1,3 @@
# Dragonfly Project Governance # Dragonfly Project Governance
As a CNCF member project, Dragonfly project abides by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). Please refer to the [community project governance](https://github.com/dragonflyoss/community/blob/master/GOVERNANCE.md).
This doc outlines the responsibilities of contributor roles in Dragonfly. The Dragonfly project is subdivided into sub-projects
under (predominantly, but not exclusively) nydus, nydus-snapshotter, api, docs, console and client.
Responsibilities for roles are scoped to these sub-projects (repos).
We have six levels of responsibility including:
- Contributor
- Member
- Approver
- Maintainer
- Administrator
## Contributor
A Contributor is someone who has contributed to the project by submitting code, issues, or participating in discussions.
### Responsibilities
- Contribute code changes via pull requests (PRs).
- Raise issues for bugs, enhancements, or other discussions.
- Participate in code reviews if requested.
- Follow the project's Code of Conduct and contribution guidelines.
### Requirements
- Have a GitHub account.
- Sign the Contributor License Agreement (if applicable).
- Adhere to the project's coding standards and guidelines.Contributor
## Member
A Member is a contributor who has shown long-term commitment to the project,
consistently contributing high-quality work and actively participating in the community.
Responsibilities:
- All responsibilities of a Contributor.
- Participate in project planning and decision-making processes.
- Mentor new contributors.
- Actively participate in community meetings and discussions.
Requirements:
- Demonstrated history of contributions (code, reviews, discussions) over at least 3 months.
- Invitation by a Maintainer or Administrator based on consensus.
- Continued adherence to the project's Code of Conduct.
## Approver
An Approver is a member who has the additional responsibility of reviewing and approving PRs that affect the project.
Responsibilities:
- All responsibilities of a Member.
- Review and approve PRs from Contributors and Members.
- Ensure that changes adhere to coding standards, do not introduce bugs, and improve the project.
- Help triage issues and provide feedback on improvements.
Requirements:
- Demonstrated expertise in the project’s codebase.
- Consistent and high-quality contributions.
- Trusted by Maintainers and Administrators to provide accurate reviews and approvals.
## Maintainer
A Maintainer is an experienced and trusted member who has extensive knowledge of the project, including architecture
and design principles. Maintainers have the authority to merge PRs and make significant project decisions.
Responsibilities:
- All responsibilities of an Approver.
- Merge PRs to the main branch.
- Ensure the overall quality, stability, and performance of the codebase.
- Coordinate releases and update documentation.
- Guide the project's technical direction and roadmap.
- Facilitate communication and collaboration within the community.
Requirements:
- Demonstrated long-term, high-quality contributions and leadership in the project.
- Deep understanding of the project’s architecture and design.
- Commitment to the project's goals and values.
- Nominated and approved by existing Maintainers and Administrators.
### Maintainership
Maintainers of Dragonfly share the responsibility. And they have 3 things in general:
- share responsibility in the project's success;
- make a long-term investment to improve the project;
- spend time doing whatever needs to, not only the most interesting part;
Maintainers are often working hard, but sometimes what they do is hardly appreciate.
It is easy to work on the fancy part or technically advanced feature. It is harder
to work on minor bugfix, small improvement, long-term stable optimization or
others. While all of the above is the essential parts to build up a successful project.
### Adding Maintainers
Maintainers are foremost and first contributors that have dedicated to the long
term success of the project. Contributors wishing to become maintainers are
expected to deeply involved in tackling issues, contributing codes, review
proposals and codes for more than two months.
Maintainership is built on trust. Trust is totally beyond just contributing
code. Thus it is definitely worthy to achieving current maintainers' trust via
bringing best interest for the project.
Current maintainers will hold a maintainer meeting periodically. During the
meeting, filtering a list of active contributors that have proven to invest
regular time on project over the prior months. From the list, if maintainers
find that one or more are qualified candidates, then a proposal of adding
maintainers can be submitted to GitHub via a pull request. If a vote of at
least 50% agree with the proposal, the newly added maintainer must be treated
valid.
### Removal of Inactive Maintainers
Similar to adding maintainers, existing maintainer can been removed from the
active maintainer list. If the existing maintainer meet one of the conditions
below, any other maintainers can proposed to remove him from active list via a
pull request:
- A maintainer has not participated in community activities for more than last
three months;
- A maintainer did not obey to the governance rules more than twice;
After confirming conditions above, in theory maintainer can be removed from
list directly unless the original maintainer requests to remain maintainer seat
and gets a vote of at least 50% of other maintainers.
If a maintainer is removed from the maintaining list, other maintainers should
at a column to the alumni part to thank the contribution made from the inactive
maintainer.
### How to make decision
Dragonfly is an open-source project illustrating the concept of open. This
means that Dragonfly repository is the source of truth for every aspect of the
project, including raw value, design, doc, roadmap, interfaces and so on. If it
is one part of the project, it should be in the repo.
To be honest, all decisions can be regarded as an update to project.
Any updates or changes which take effect on Dragonfly, no matter big or small,
should follow three steps below:
- Step 1: Open a pull request;
- Step 2: Discuss under the pull request;
- Step 3: Merge or refuse the pull request.
When Dragonfly has less than seven maintainers, a pull request except adding
maintainers pull request could be merged, if it meets both conditions below:
- at least one maintainer commented `LGTM` to the pull request;
- no other maintainers have opposite opinion on it.
When Dragonfly has more than seven maintainers, a pull request except adding
maintainers pull request could be merged, if it meets conditions below:
- at least two maintainers commented `LGTM` to the pull request;
### Updating Governance
All substantive updates in Governance require a supermajority maintainers vote.
## Administrator
An Administrator has the highest level of access and responsibility in the project. They manage overall project governance,
ensure adherence to policies, and resolve conflicts within the community.
Responsibilities:
- All responsibilities of a Maintainer.
- Manage project settings and permissions.
- Ensure compliance with legal and organizational policies.
- Handle CoC violations and mediate conflicts.
- Facilitate election of new roles or changes in the governance structure.
Requirements:
- Proven contribution history and leadership within the project.
- Strong understanding of open-source community management.
- Trusted by the community and other Administrators.
- Appointed through consensus of current Administrators.

4
README.md
View File

@ -80,7 +80,7 @@ Please refer to our [Code of Conduct][codeconduct].
[arch]: docs/images/arch.png [arch]: docs/images/arch.png
[logo-linear]: docs/images/logo/dragonfly-linear.svg [logo-linear]: docs/images/logo/dragonfly-linear.svg
[discussion]: https://github.com/dragonflyoss/dragonfly/discussions [discussion]: https://github.com/dragonflyoss/dragonfly/discussions
[contributing]: CONTRIBUTING.md [contributing]: https://github.com/dragonflyoss/community/blob/master/CONTRIBUTING.md
[codeconduct]: CODE_OF_CONDUCT.md [codeconduct]: https://github.com/dragonflyoss/community/blob/master/CODE_OF_CONDUCT.md
[d7y.io]: https://d7y.io/ [d7y.io]: https://d7y.io/
[dingtalk]: docs/images/community/dingtalk-group.jpeg [dingtalk]: docs/images/community/dingtalk-group.jpeg

51
SECURITY.md
View File

@ -1,52 +1,3 @@
# Security Policy # Security Policy
## Reporting a Vulnerability Please refer to the [community security policy](https://github.com/dragonflyoss/community/blob/master/SECURITY.md).
To report a Dragonfly vulnerability:
1. Navigate to the security tab on the repository GitHub Security Tab.
2. Click on Advisories GitHub Advisories tab.
3. Click on Report a vulnerability.
The reporter(s) can expect a response within 24 hours acknowledging the issue was received.
If a response is not received within 24 hours, please reach out to any committer directly to confirm receipt of the issue.
## Review Process
Once a committer has confirmed the relevance of the report, a draft security advisory will be created on GitHub.
The draft advisory will be used to discuss the issue with committers, the reporter(s), and Dragonfly's security advisors.
If the reporter(s) wishes to participate in this discussion, then provide reporter GitHub username(s) to be invited
to the discussion. If the reporter(s) does not wish to participate directly in the discussion,
then the reporter(s) can request to be updated regularly via email.
If the vulnerability is accepted, a timeline for developing a patch, public disclosure, and patch release will be
determined. If there is an embargo period on public disclosure before the patch release,
an announcement will be sent to the security announce mailing list <dragonfly-developers@googlegroups.com> announcing
the scope of the vulnerability, the date of availability of the patch release, and the date of public disclosure.
The reporter(s) are expected to participate in the discussion of the timeline and abide by agreed-upon dates for public disclosure.
## Supported Versions
See the Dragonfly releases page for information on supported versions of Dragonfly.
Any Extended or Active release branch may receive security updates. For any security issues discovered
on older versions, non-core packages, or dependencies, please inform committers using
the same security mailing list as for reporting vulnerabilities.
## Joining the Security Announce Mailing List
Any organization or individual who directly uses Dragonfly and non-core packages in production or in a
security-critical application is eligible to join the security announce mailing list. Indirect users
who use Dragonfly through a vendor are not expected to join but should request their vendor join.
To join the mailing list, the individual or organization must be sponsored by either a Dragonfly committer or
security advisor as well as have a record of properly handling non-public security information.
Sponsorship should not be requested via public channels since membership of the security announce list is not public.
### Mailing Lists
- **dragonfly-developers@googlegroups.com**: Report security concerns.
### Confidentiality, Integrity, and Availability
We prioritize vulnerabilities that compromise data confidentiality, privilege elevation, or integrity.
Availability issues, such as DoS and resource exhaustion, are also serious concerns.
Operators must configure settings, role-based access control, and other features to provide a hardened environment.