Compare commits
1 Commits
master
...
archiving-
| Author | SHA1 | Date |
|---|---|---|
Chris Aniszczyk
|
614f83aa61 |
|
|
@ -37,7 +37,6 @@ List below is the official list of TOC contributors, in alphabetical order:
|
|||
* Drew Rapenchuk, Bloomberg (drapenchuk@bloomberg.net)
|
||||
* Dustin Kirkland, Canonical (kirkland@canonical.com)
|
||||
* Eduardo Silva, Treasure Data (eduardo@treasure-data.com)
|
||||
* Edward Lee, Intuit (edward_lee@intuit.com)
|
||||
* Erin Boyd, Red Hat (eboyd@redhat.com)
|
||||
* Gergely Csatari, Nokia (gergely.csatari@nokia.com)
|
||||
* Ghe Rivero, Independent (ghe.rivero@gmail.com)
|
||||
|
|
|
|||
|
|
@ -95,13 +95,14 @@ Here is a link to a World Time Zone Converter here http://www.thetimezoneconvert
|
|||
[CloudEvents](https://github.com/cloudevents)|Brian Grant, Ken Owens|[11/14/17](https://goo.gl/vKbawR)|[5/22/18](https://www.cncf.io/blog/2018/05/22/cloudevents-in-the-sandbox/)|Sandbox
|
||||
[Telepresence](https://github.com/telepresenceio)|Alexis Richardson, Camille Fournier|[4/17/18](https://docs.google.com/presentation/d/1VrHKGre5Y8AbmXEOXu4VPfILReoLT38Uw9TMN71u08E/edit?usp=sharing)|[5/22/18](https://www.cncf.io/blog/2018/05/22/telepresence-in-the-sandbox/)|Sandbox
|
||||
[Helm](https://github.com/helm)|Brian Grant|[5/15/18](https://docs.google.com/presentation/d/1KNSv70fyTfSqUerCnccV7eEC_ynhLsm9A_kjnlmU_t0/edit#slide=id.g25ca91f87f_0_0)|[6/1/18](https://www.cncf.io/blog/2018/06/01/cncf-to-host-helm/)|Incubating
|
||||
[Harbor](https://github.com/goharbor)|Quinton Hoole, Ken Owens|[6/19/18](https://docs.google.com/presentation/d/1KNSv70fyTfSqUerCnccV7eEC_ynhLsm9A_kjnlmU_t0/edit#slide=id.g25ca91f87f_0_0)|[7/31/18](https://www.cncf.io/blog/2018/07/31/cncf-to-host-harbor-in-the-sandbox/)|Incubating
|
||||
[Harbor](https://github.com/goharbor)|Quinton Hoole, Ken Owens|[6/19/18](https://docs.google.com/presentation/d/1KNSv70fyTfSqUerCnccV7eEC_ynhLsm9A_kjnlmU_t0/edit#slide=id.g25ca91f87f_0_0)|[7/31/18](https://www.cncf.io/blog/2018/07/31/cncf-to-host-harbor-in-the-sandbox/)|Sandbox
|
||||
[OpenMetrics](https://github.com/OpenObservability/OpenMetrics)|Alexis Richardson, Bryan Cantrill|[6/20/17](https://goo.gl/6nmyDn)|[8/10/18](https://www.cncf.io/blog/2018/08/10/cncf-to-host-openmetrics/)|Sandbox
|
||||
[TiKV](https://github.com/tikv/tikv)|Ben Hindman, Bryan Cantrill|[7/3/18](https://docs.google.com/presentation/d/1864TEfbwCpbW5kPYGQNAfqAUdc3X83n-_OYigqxfohw/edit?usp=sharing)|[8/28/18](https://www.cncf.io/blog/2018/08/28/cncf-to-host-tikv/)|Sandbox
|
||||
[Cortex](https://github.com/cortexproject/cortex)|Ken Owens, Bryan Cantrill|[6/5/18](https://docs.google.com/presentation/d/190oIFgujktVYxWZLhLYN4q8p9dtQYoe4sxHgn4deBSI/edit#slide=id.g25ca91f87f_0_0)|[9/20/18](https://www.cncf.io/blog/2018/09/20/cncf-to-host-in-the-sandbox/)|Sandbox
|
||||
[Buildpacks](https://github.com/buildpack/spec)|Brian Grant, Alexis Richardson|[8/21/18](https://docs.google.com/presentation/d/1RkygwZw7ILVgGhBpKnFNgJ4BCc_9qMG8cIf0MRbuzB4/edit?usp=sharing)|[10/3/18](https://www.cncf.io/blog/2018/10/03/cncf-to-host-cloud-native-buildpacks-in-the-sandbox)|Sandbox
|
||||
[Falco](https://github.com/falcosecurity/falco)|Brian Grant, Quinton Hoole|[7/17/18](https://docs.google.com/presentation/d/17p5QBVooGMLAtX6Mn6d3NAFhRmFHE0cH-WI_-0MbOm8/edit?usp=sharing)|[10/10/18](https://falco.org/)|Sandbox
|
||||
[Dragonfly](https://github.com/dragonflyoss/dragonfly)|Jonathan Boulle, Benjamin Hindman|[9/4/18](https://docs.google.com/presentation/d/1umu-iT5ZXq5XsMFmqmVeRe-tn2y7DeSoCebhrehi7fk/edit#slide=id.g41381b8fd7_0_199)|[11/15/18](https://github.com/oss/dragonfly)|Sandbox
|
||||
|
||||
Quinton Hoole, Brian Grant
|
||||
|
||||
## Website Guidelines
|
||||
|
||||
|
|
@ -159,8 +160,8 @@ If you're interested in presenting at a TOC call about your project, please open
|
|||
* **Sep 4, 2018**: OpenMessaging/Dragonfly
|
||||
* **Sep 18, 2018**: netdata
|
||||
* **Oct 2, 2018**: keycloak
|
||||
* **Nov 20, 2018**: Graduation/Project Reviews
|
||||
* **Oct 16, 2018**: (interested presenters contact cra@linuxfoundation.org or open up a github [issue](https://github.com/cncf/toc/issues))
|
||||
* **Nov 6, 2018**: Graduation/Project Reviews: TUF
|
||||
|
||||
## Meeting Minutes
|
||||
|
||||
|
|
|
|||
|
|
@ -1,100 +0,0 @@
|
|||
# Due Diligence Project Review Template
|
||||
This page provides project review guidelines to those leading or contributing to due diligence exercises performed by or on behalf of the Technical Oversight Committee of the CNCF.
|
||||
|
||||
## Introduction
|
||||
The decision to graduate or promote a project depend on the TOC sponsors of the project performina dn documenting the evaluation process in deciding upon initial or continued inclusion of projects through a Technical Due Diligence ('Tech DD') exercise. Ultimately the voting members of the TOC will, on the basis of this and other information, vote for or against the inclusion of each project at the relevant time.
|
||||
|
||||
## Technical Due Diligence
|
||||
### Primary Goals
|
||||
To enable the voting TOC members to cast an informed vote about a project, it is crucial that each member is able to form their own opinion as to whether and to what extent the project meets the agreed upon criteria for sandbox, incubation or graduation. As the leader of a DD, your job is to make sure that they have whatever information they need, succinctly and readily available, to form that opinion.
|
||||
|
||||
As a secondary goal, it is in the interests of the broader CNCF ecosystem that there exists some reasonable degree of consensus across the community regarding the inclusion or otherwise of projects at the various maturity levels. Making sure that the relevant information is available, and any disagreement or misunderstanding as to it's validity are ideally resolved, helps to foster this consensus.
|
||||
|
||||
## Statment of CNCF Alignment to TOC Principles
|
||||
1. Project is self-goverrning
|
||||
2. Is there a documented Code of Conduct that adhears to the CNCF guidelines?
|
||||
3. Does the project have production deployments that are high quality and high-velocity? (for incubation and graduated projects).
|
||||
(Sandbox level projects are targeted at earlier-stage projects to cultivate a community/technology)
|
||||
4. Is the project committed to acheiving the CNCF principls and do they have a committed roadmap to address any areas of concern raised by the community?
|
||||
5. The project needs to be reviewed and dosucment that the project has a fundamentally sound design without obvious critical compromises that will inhibit potential widespread adoption
|
||||
6. Document that the project is useful for cloud native deployments & degree that its architected in a cloud native style
|
||||
7. Document that the project has an affinity for how CNCF operates and understand the expectation of being a CNCF project.
|
||||
|
||||
## Review of graduation criteria and desired cloud native properties
|
||||
/* Use appropriate Section */
|
||||
|
||||
### Sandbox Graduation (Exit Requirements)
|
||||
1. Document that it is being used successfully in production by at least three independent end users which with focus on adequate quality and scope defined.
|
||||
2. Have a healthy number of committers. A committer is defined as someone with the commit bit; i.e., someone who can accept contributions to some or all of the project.
|
||||
3. Demonstrate a substantial ongoing flow of commits and merged contributions.
|
||||
|
||||
### Incubating Stage Graduation (Exit Requirements)
|
||||
1. Document that it is being used successfully in production by at least three independent end users which with focus on adequate quality and scope defined.
|
||||
2. Have a healthy number of committers. A committer is defined as someone with the commit bit; i.e., someone who can accept contributions to some or all of the project.
|
||||
3. Demonstrate a substantial ongoing flow of commits and merged contributions.
|
||||
4. Have committers from at least two organizations.
|
||||
5. Have achieved and maintained a Core Infrastructure Initiative Best Practices Badge.
|
||||
6. Adopted the CNCF Code of Conduct.
|
||||
7. Explicitly define a project governance and committer process. This preferably is laid out in a GOVERNANCE.md file and references an OWNERS.md file showing the current and emeritus committers.
|
||||
8. Have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website).
|
||||
|
||||
### Documentation of CNCF Alignment (if not addressed above):
|
||||
name of project (must be unique within CNCF)
|
||||
project description (what it does, why it is valuable, origin and history)
|
||||
statement on alignment with CNCF charter mission
|
||||
sponsor from TOC (sponsor helps mentor projects)
|
||||
license (charter dictates Apache 2 by default)
|
||||
source control (GitHub by default)
|
||||
external dependencies (including licenses)
|
||||
release methodology and mechanics
|
||||
community size and any existing sponsorship
|
||||
|
||||
##Technical
|
||||
* An architectural, design and feature overview should be available. (add link)
|
||||
* What are the primary target cloud-native use cases? Which of those:
|
||||
* Can be accomplished now.
|
||||
* Can be accomplished with reasonable additional effort (and are ideally already on the project roadmap).
|
||||
* Are in-scope but beyond the current roadmap.
|
||||
* Are out of scope.
|
||||
* What are the current performance, scalability and resource consumption bounds of the software? Have these been explicitly tested? Are they appropriate given the intended usage (e.g. agent-per-node or agent-per-container need to be lightweight, etc)?
|
||||
* What exactly are the failure modes? Are they well understood? Have they been tested? Do they form part of continuous integration testing? Are they appropriate given the intended usage (e.g. cluster-wide shared services need to fail gracefully etc)?
|
||||
* What trade-offs have been made regarding performance, scalability, complexity, reliability, security etc? Are these trade-offs explicit or implicit? Why? Are they appropriate given the intended usage? Are they user-tunable?
|
||||
* What are the most important holes? No HA? 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?
|
||||
* What is the release model? Versioning scheme? Evidence of stability or otherwise of past stable released versions?
|
||||
* What is the CI/CD status? Do explicit code coverage metrics exist? If not, what is the subjective adequacy of automated testing? Do different levels of tests exist (e.g. unit, integration, interface, end-to-end), or is there only partial coverage in this regard? Why?
|
||||
* What licensing restrictions apply? Again, CNCF staff will handle the full legal due diligence.
|
||||
* What are the recommended operational models? Specifically, how is it operated in a cloud-native environment, such as on Kubernetes?
|
||||
|
||||
## Project
|
||||
* Do we believe this is a growing, thriving project with committed contributors?
|
||||
* Is it aligned with CNCF's values and mission?
|
||||
* Do we believe it could eventually meet the graduation criteria?
|
||||
* Should it start at the sandbox level or incubation level?
|
||||
* Does ithe project have a sound, documented process for source control, issue tracking, release management etc.
|
||||
* Does it have a documented process for adding committers?
|
||||
* Does it have a documented governance model of any kind?
|
||||
* Does it have committers from multiple organizations?
|
||||
* Does it have a code of conduct?
|
||||
* 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.
|
||||
* What is the general quality of informal communication around the project (slack, github issues, PR reviews, technical blog posts, etc)?
|
||||
* How much time does the core team commit to the project?
|
||||
* How big is the team? Who funds them? Why? How much? For how long?
|
||||
* Who are the clear leaders? Are there any areas lacking clear leadership? Testing? Release? Documentation? These roles sometimes go unfilled.
|
||||
* Besides the core team, how active is the surrounding community? Bug reports? Assistance to newcomers? Blog posts etc.
|
||||
* Do they make it easy to contribute to the project? If not, what are the main obstacles?
|
||||
* Are there any especially difficult personalities to deal with? How is this done? Is it a problem?
|
||||
* What is the rate of ongoing contributions to the project (typically in the form of merged commits).
|
||||
|
||||
## Users
|
||||
* Who uses the project? Get a few in-depth references from 2-4 of them who actually know and understand it.
|
||||
* What do real users consider to be it's strengths and weaknesses? Any concrete examples of these?
|
||||
* Perception vs Reality: Is there lots of buzz, but the software is flaky/untested/unused? Does it have a bad reputation for some flaw that has already been addressed?
|
||||
|
||||
## Context
|
||||
* What is the origin and history of the project?
|
||||
* Where does it fit in the market and technical ecosystem?
|
||||
* Is it growing or shrinking in that space? Is that space growing or shrinking?
|
||||
* How necessary is it? What do people who don't use this project do? Why exactly is that not adequate, and in what situations?
|
||||
* Clearly compare and contrast with peers in this space. A summary matrix often helps. Beware of comparisons that are too superficial to be useful, or might have been manipulated so as to favor some projects over others. Most balanced comparisons will include both strengths and weaknesses, require significant detailed research, and usually there is no hands-down winner. Be suspicious if there appears to be one.
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
# CNCF Project Archiving Process v1.0
|
||||
|
||||
Open source projects have a lifecycle and there are times that projects become inactive due to a variety of reasons. There are also cases where a project may no longer want to be supported by the TOC.
|
||||
|
||||
## Archiving Criteria
|
||||
|
||||
There are different criteria to consider when archiving a project, but here are ones that the TOC looks for:
|
||||
|
||||
* It hasn't seen a commit in over 6 months.
|
||||
* It hasn't seen a release in over 6 months.
|
||||
* There haven't been any issues opened for 6 months.
|
||||
* Opened issues haven't received a response within 6 months.
|
||||
* It's binaries/source are no longer being downloaded
|
||||
|
||||
It is important to note that there is a difference between a mature project that doesn't get much attention anymore but is stable versus a project that is inactive.
|
||||
|
||||
## Voting Process
|
||||
|
||||
To archive a project:
|
||||
|
||||
* A proposal must be put forth to the TOC repo and be open for at least 2 weeks of discussion.
|
||||
* The TOC will inform the CNCF end user community and wider community of all archiving proposals
|
||||
* A vote must be finalized with 2/3 approval from the TOC
|
||||
|
||||
## Archiving Process
|
||||
|
||||
What does archiving for a CNCF project mean?
|
||||
|
||||
* CNCF will no longer provide any support for the project, via service desk
|
||||
* CNCF will list archived projects online
|
||||
* Archived CNCF projects will be transferred to the Linux Foundation for neutral holding and support
|
||||
|
||||
## Reactivating an Archived Project
|
||||
|
||||
Any project can be reactivated into CNCF by finally the normal project [proposal](https://github.com/cncf/toc/blob/master/process/project_proposals.adoc) and [sandbox](https://github.com/cncf/toc/blob/master/process/sandbox.md) process.
|
||||
|
|
@ -8,21 +8,21 @@ The key sections of the [charter](https://www.cncf.io/about/charter/) are:
|
|||
|
||||
>6(c)(i) The TOC shall select a Chair of the TOC to set agendas and call meetings of the TOC.
|
||||
|
||||
>6(e)(ii) Nominations: Each CNCF member may nominate up to two (2) technical representatives, (from vendors, end users or any other fields), at most one of which may be from their respective company. The nominee(s) must agree to participate prior to being added to the nomination list.
|
||||
>6(e)(ii) Nominations: Each individual (entity or member) eligible to nominate a TOC member may nominate up to two (2) technical representatives, (from vendors, end users or any other fields), at most one of which may be from their respective company.
|
||||
|
||||
>6(f)(i) TOC Members shall serve two-year, staggered terms. The initial six elected TOC members from the Governing Board election shall serve an initial term of three (3) years. The TOC members initially elected by the End User TAB and TOC shall serve an initial term of two (2) years.
|
||||
|
||||
Current TOC [Members](https://github.com/cncf/toc#members) and their terms are:
|
||||
|
||||
* Jonathan Boulle (term: 3 years - start date: 1/29/2016) [GB appointed]
|
||||
* Bryan Cantrill (term: 3 years - start date: 1/29/2016) [GB appointed]
|
||||
* Camille Fournier (term: 3 years - start date: 1/29/2016) [GB appointed]
|
||||
* Brian Grant (term: 2 years - start date: 3/17/2018) [TOC appointed]
|
||||
* Benjamin Hindman (term: 3 years - start date: 1/29/2016) [GB appointed]
|
||||
* Quinton Hoole (term: 1 year - start date: 3/17/2018) [TOC appointed]
|
||||
* Sam Lambert (term: 16 months - start date: 10/2/2017) [enduser appointed]
|
||||
* Ken Owens (term: 3 years - start date: 1/29/2016) [GB appointed]
|
||||
* Alexis Richardson (term: 3 years - start date: 1/29/2016) [GB appointed]
|
||||
* Jonathan Boulle (term: 3 years - start date: 1/29/2016)
|
||||
* Bryan Cantrill (term: 3 years - start date: 1/29/2016)
|
||||
* Camille Fournier (term: 3 years - start date: 1/29/2016)
|
||||
* Brian Grant (term: 2 years - start date: 3/17/2018)
|
||||
* Benjamin Hindman (term: 3 years - start date: 1/29/2016)
|
||||
* Quinton Hoole (term: 1 year - start date: 3/17/2018)
|
||||
* Sam Lambert (term: 16 months - start date: 10/2/2017)
|
||||
* Ken Owens (term: 3 years - start date: 1/29/2016)
|
||||
* Alexis Richardson (term: 3 years - start date: 1/29/2016)
|
||||
|
||||
On 1/29/2019, the other 6 TOC positions are up for re-election by the GB. The charter requires that the initial appointments have been for 3 years (which they were), but to use staggered, 2-year terms going forward. We propose that half of the positions get a 1-year term in just that cycle (by drawing straws), so that each year afterwards, 3 of the 6 will be reappointed or replaced.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,119 +0,0 @@
|
|||
=== Dragonfly CNCF Sandbox Project Proposal
|
||||
|
||||
*Name of Project:* Dragonfly
|
||||
|
||||
*Description:*
|
||||
|
||||
Dragonfly is an intelligent P2P based image and file distribution system. It aims to resolve three major issues: efficiency, flow control and security.
|
||||
|
||||
It is a general tool which can be integrated with container engine to help deploy cloud native applications at scale. In addition, users can deploy Dragonfly easily on Kubernetes via Helm and daemonset.
|
||||
|
||||
Dragonfly ensures distribution efficiency of images with P2P policy, the avoidance of duplicated image downloads. To not impact the other running applications, Dragonfly implements image distribution flow control, such as download bandwidth limit and disk IO protection. Dragonfly also takes advantages of encryption algorithm for image transmission in order to meet secure demand of enterprise. Here are some key features of Dragonfly:
|
||||
|
||||
* P2P based file distribution
|
||||
* Support a wide range of container technologies
|
||||
* Host level speed limit
|
||||
* Passive CDN for downloads
|
||||
* Strong consistency of distributed image
|
||||
* Disk protection and high efficient IO
|
||||
* High performance
|
||||
* Exception auto isolation
|
||||
* Effective concurrency control of Registry Auth
|
||||
* Image encryption when transmission
|
||||
|
||||
Dragonfly consists of three major components:
|
||||
|
||||
1. **SuperNode**: provides image cache services from source image registry; chooses appropriate downloading policy for each peer.
|
||||
|
||||
1. **dfget**: is a client which downloads files from P2P network(peer nodes and SuperNode); receives control orders from SuperNode and transfers data among P2P network.
|
||||
|
||||
1. **dfdaemon**: is an agent which proxies image pulling request from local container engine; filters out layer fetching requests and uses dfget to download all these layers.
|
||||
|
||||
**Statement on alignment with CNCF mission:**
|
||||
|
||||
The Cloud Native Dragonfly project is well-aligned with the CNCF's mission statement of supporting cloud native systems. When developers and operators finish to package applications in container images, Dragonfly aims to tackle distribution issue of packaged image distribution(1a). The intelligent distribution ability of Dragonfly can dynamically manage network bandwidth, disk IO and other resources efficiently to reduce maintenance and operation cost(1b). Dragonfly is decoupled with dependencies and designed to be consist of explicit and minimal services within itself(1c).
|
||||
|
||||
The Cloud Native Dragonfly project is complimentary to other CNCF projects, such as Kubernetes, Helm, Harbor and containerd. SuperNode of Dragonfly can be deployed via Helm and dfget and dfdaemon agents can be deployed via daemonset of Kubernetes. When releasing a cloud native application in Kubernetes, Harbor takes advantanges of Dragonfly's open API to control the image preheater. when startup of pod, containerd sends image pull request to Dragonfly and Dragonfly takes over image distribution part automatically, efficiently and safely.
|
||||
|
||||
*Roadmap:*
|
||||
|
||||
Dragonfly intends to deliver more essential and advanced feature in ecosystem openness, scalability and security. For more details, please refer to https://github.com/alibaba/Dragonfly/blob/master/ROADMAP.md[ROADMAP].
|
||||
|
||||
*Sponsors from TOC:* Jonathan Boulle & Benjamin Hindman
|
||||
|
||||
*Preferred maturity level:* Sandbox
|
||||
|
||||
*License:* Apache License v2.0
|
||||
|
||||
*Source control:* GitHub (https://github.com/alibaba/dragonfly)
|
||||
|
||||
*External Dependencies:*
|
||||
|
||||
External dependencies of Falco are listed below:
|
||||
|===
|
||||
|*Software*|*License*|*Project Page*
|
||||
|
||||
|go-check|BSD|https://github.com/go-check/check/[https://github.com/go-check/check/]
|
||||
|compress|BSD|https://github.com/klauspost/compress[https://github.com/klauspost/compress]
|
||||
|cpuid|MIT|https://github.com/klauspost/cpuid[https://github.com/klauspost/cpuid]
|
||||
|uuid|BSD|https://github.com/pborman/uuid[https://github.com/pborman/uuid]
|
||||
|logrus|MIT|https://github.com/sirupsen/logrus[https://github.com/sirupsen/logrus]
|
||||
|pflag|BSD|https://github.com/spf13/pflag[https://github.com/spf13/pflag]
|
||||
|bytebufferpool|MIT|https://github.com/valyala/bytebufferpool[https://github.com/valyala/bytebufferpool]
|
||||
|fasthttp|MIT|https://github.com/valyala/fasthttp[https://github.com/valyala/fasthttp]
|
||||
|terminal|BSD|https://golang.org/x/crypto/ssh/terminal[https://golang.org/x/crypto/ssh/terminal]
|
||||
|unix|MIT|https://golang.org/x/sys/unix[https://golang.org/x/sys/unix]
|
||||
|windows|zlib|https://golang.org/x/sys/windows[https://golang.org/x/sys/windows]
|
||||
|gcfg|BSD|https://gopkg.in/gcfg.v1[https://gopkg.in/gcfg.v1]
|
||||
|yaml|Apache License 2.0|https://gopkg.in/yaml.v2[https://gopkg.in/yaml.v2]
|
||||
|===
|
||||
|
||||
*Initial Committers:*
|
||||
|
||||
Founding Maintainers:
|
||||
|
||||
* Allen Sun (Alibaba)
|
||||
* Chaobing Chen (Meitu)
|
||||
* Jian Wang (Alibaba)
|
||||
* Jin Zhang (Alibaba)
|
||||
* Zuozheng Hu (Alibaba)
|
||||
|
||||
Additional Maintainers:
|
||||
|
||||
* Haibing Zhou (Ebay China)
|
||||
|
||||
*Infrastructure requests (CI / CNCF Cluster):*
|
||||
|
||||
_Development needs:_
|
||||
|
||||
We currently use Travis and CircleCI for CI, but we may want to use CNCF resources to deploy jenkis for node e2e test.
|
||||
|
||||
_Production needs:_
|
||||
|
||||
none
|
||||
|
||||
*Communication Channels:*
|
||||
|
||||
* Gitter: https://gitter.im/alibaba/Dragonfly
|
||||
* Mailing List: https://lists.cncf.io/g/cncf-dragonfly (proposed)
|
||||
* Issue tracker: https://github.com/alibaba/Dragonfly/issues
|
||||
|
||||
*Website:* https://alibaba.github.io/Dragonfly/
|
||||
|
||||
*Release methodology and mechanics:*
|
||||
|
||||
We set the version rule of Dragonfly on the basis of SemVer which has a version number of MAJOR.MINOR.PATCH. Currently we do feature release 4-5 times per year(all with minor releases). Before every minor release, we plan to tag several RC releases to invite community developers to fully test them. In addition, all the code commits to Dragonfly project must add essential tests to cover the feature or code change.
|
||||
|
||||
*Social media accounts:*
|
||||
|
||||
* Twitter: https://twitter.com/dragonfly_oss[@dragonfly_oss]
|
||||
|
||||
*Existing sponsorship*: Alibaba, AntFinancial and China Mobile
|
||||
|
||||
*Community size:*
|
||||
|
||||
2300+ stars
|
||||
|
||||
3 full-time engineers
|
||||
|
||||
16 contributors
|
||||
|
|
@ -1,80 +0,0 @@
|
|||
# Harbor Incubating Stage Review
|
||||
|
||||
Harbor is currently a CNCF sandbox project. Please refer to Harbor's initial
|
||||
[sandbox proposal](../proposals/harbor.adoc) for discussion on Harbor's
|
||||
alignment with the CNCF and details on sandbox requirements.
|
||||
|
||||
In the time since being accepted as a sandbox project, Harbor has demonstrated
|
||||
healthy growth and progress.
|
||||
|
||||
* [v1.6.0 is the latest
|
||||
releases](https://goharbor.io/blogs/harbor-1.6.0-release/), shipped on
|
||||
September 7th, marking our 7th major feature release. New features include:
|
||||
|
||||
* [Support for hosting Helm charts](https://github.com/goharbor/harbor/issues/4922)
|
||||
* [Support for RBAC via LDAP groups](https://github.com/goharbor/harbor/issues/3506)
|
||||
* [Replication filtering via labels](https://github.com/goharbor/harbor/issues/4861)
|
||||
* [Major refactoring to coalesce to a single PostgreSQL database](https://github.com/goharbor/harbor/issues/4855)
|
||||
|
||||
* A [formalized governance
|
||||
policy](https://github.com/goharbor/community/blob/master/GOVERNANCE.md) has
|
||||
been approved and instituted for the project, and two new maintainers from
|
||||
different companies have joined the project to help Harbor continue to grow.
|
||||
|
||||
## Incubating Stage Criteria
|
||||
|
||||
In addition to sandbox requirements, a project must meet the following
|
||||
criteria to become an incubation-stage project:
|
||||
|
||||
* Document that it is being used successfully in production by at least three
|
||||
independent end users which, in the TOC’s judgement, are of adequate quality
|
||||
and scope.
|
||||
|
||||
* Adopters: [https://github.com/goharbor/harbor/blob/master/ADOPTERS.md](https://github.com/goharbor/harbor/blob/master/ADOPTERS.md)
|
||||
|
||||
* Have a healthy number of committers. A committer is defined as someone with
|
||||
the commit bit; i.e., someone who can accept contributions to some or all of
|
||||
the project.
|
||||
|
||||
* Maintainers of the project are listed in
|
||||
[https://github.com/goharbor/harbor/blob/master/OWNERS.md](https://github.com/goharbor/harbor/blob/master/OWNERS.md). There are 11 maintainers working on Harbor from 3 different
|
||||
companies (VMware, Caicloud and Hyland Software)
|
||||
|
||||
* Maintainers are added and removed from the project as per the policies
|
||||
outlined in the project governance:
|
||||
[https://github.com/goharbor/community/blob/master/GOVERNANCE.md](https://github.com/goharbor/community/blob/master/GOVERNANCE.md).
|
||||
|
||||
* Demonstrate a substantial ongoing flow of commits and merged contributions.
|
||||
|
||||
* Releases: 7 major releases ([https://github.com/goharbor/harbor/releases](https://github.com/goharbor/harbor/releases))
|
||||
|
||||
* Roadmap: [https://github.com/goharbor/harbor/wiki/Harbor-Roadmap](https://github.com/goharbor/harbor/wiki/Harbor-Roadmap)
|
||||
|
||||
* Contributors: [https://github.com/goharbor/harbor/graphs/contributors](https://github.com/goharbor/harbor/graphs/contributors)
|
||||
|
||||
* Commit activity: [https://github.com/goharbor/harbor/graphs/commit-activity](https://github.com/goharbor/harbor/graphs/commit-activity)
|
||||
|
||||
* CNCF DevStats: [https://harbor.devstats.cncf.io/](https://harbor.devstats.cncf.io/)
|
||||
* [Last 30 days activity on GitHub](https://harbor.devstats.cncf.io/d/8/dashboards?refresh=15m&orgId=1&from=now-30d&to=now-1h)
|
||||
* [Community Stats](https://harbor.devstats.cncf.io/d/3/community-stats?orgId=1&var-period=d7&var-repo_name=goharbor%2Fharbor)
|
||||
|
||||
Further details of Harbor's growth and progress since entering the sandbox
|
||||
stage as well as use case details from the Harbor community can be found in this
|
||||
[slide
|
||||
deck](https://docs.google.com/presentation/d/1aBQnE96kKatc1_t3E97lJBwiWvL-3GTitojuv-nWMuo/).
|
||||
|
||||
## Security
|
||||
|
||||
Harbor's codebase has been analyzed and reviewed by VMware's internal product
|
||||
security team.
|
||||
|
||||
* Static analysis has been performed on Harbor via
|
||||
[gosec](https://github.com/securego/gosec)
|
||||
* Software decomposition via AppCheck, Snyk and retire.js with goal of
|
||||
discovering outdated or vulnerable packages
|
||||
* Manual code analysis / review
|
||||
* Vulnerability assessment via multiple scanners
|
||||
* Completed threat model
|
||||
|
||||
In addition to this security work the Harbor maintainers are partnering with
|
||||
the CNCF to schedule a third-party security audit of Harbor.
|
||||
Loading…
Reference in New Issue