GOVERNANCE.md · packyzbq/istio-envoy

# Process for becoming a maintainer

## Your organization is not yet a maintainer

* Express interest to the senior maintainers that your organization is interested in becoming a
  maintainer. Becoming a maintainer generally means that you are going to be spending substantial
  time (>25%) on Envoy for the foreseeable future. You should have domain expertise and be extremely
  proficient in C++. Ultimately your goal is to become a senior maintainer that will represent your
  organization.
* We will expect you to start contributing increasingly complicated PRs, under the guidance
  of the existing senior maintainers.
* We may ask you to do some PRs from our backlog.
* As you gain experience with the code base and our standards, we will ask you to do code reviews
  for incoming PRs (i.e., all maintainers are expected to shoulder a proportional share of
  community reviews).
* After a period of approximately 2-3 months of working together and making sure we see eye to eye,
  the existing senior maintainers will confer and decide whether to grant maintainer status or not.
  We make no guarantees on the length of time this will take, but 2-3 months is the approximate
  goal.

## Your organization is currently a maintainer

* First decide whether your organization really needs more people with maintainer access. Valid
  reasons are "blast radius", a large organization that is working on multiple unrelated projects,
  etc.
* Contact a senior maintainer for your organization and express interest.
* Start doing PRs and code reviews under the guidance of your senior maintainer.
* After a period of 1-2 months the existing senior maintainers will discuss granting "standard"
  maintainer access.
* "Standard" maintainer access can be upgraded to "senior" maintainer access after another 1-2
  months of work and another conference of the existing senior committers.

## Maintainer responsibilities

* Monitor email aliases.
* Monitor Slack (delayed response is perfectly acceptable).
* Triage GitHub issues and perform pull request reviews for other maintainers and the community.
  The areas of specialization listed in [OWNERS.md](OWNERS.md) can be used to help with routing
  an issue/question to the right person.
* Triage build issues - file issues for known flaky builds or bugs, and either fix or find someone
  to fix any master build breakages.
* During GitHub issue triage, apply all applicable [labels](https://github.com/envoyproxy/envoy/labels)
  to each new issue. Labels are extremely useful for future issue follow up. Which labels to apply
  is somewhat subjective so just use your best judgment. A few of the most important labels that are
  not self explanatory are:
  * **beginner**: Mark any issue that can reasonably be accomplished by a new contributor with
    this label.
  * **help wanted**: Unless it is immediately obvious that someone is going to work on an issue (and
    if so assign it), mark it help wanted.
  * **question**: If it's unclear if an issue is immediately actionable, mark it with the
    question label. Questions are easy to search for and close out at a later time. Questions
    can be promoted to other issue types once it's clear they are actionable (at which point the
    question label should be removed).
* Make sure that ongoing PRs are moving forward at the right pace or closing them.
* Participate when called upon in the [security release process](SECURITY.md). Note that although
  this should be a rare occurrence, if a serious vulnerability is found, the process may take up to
  several full days of work to implement. This reality should be taken into account when discussing
  time commitment obligations with employers.
* In general continue to be willing to spend at least 25% of ones time working on Envoy (~1.25
  business days per week).
* We currently maintain an "on-call" rotation within the maintainers. Each on-call is 1 week.
  Although all maintainers are welcome to perform all of the above tasks, it is the on-call
  maintainer's responsibility to triage incoming issues/questions and marshal ongoing work
  forward. To reiterate, it is *not* the responsibility of the on-call maintainer to answer all
  questions and do all reviews, but it is their responsibility to make sure that everything is
  being actively covered by someone.
* The on-call rotation is tracked at Opsgenie. The calendar is visible
[here](https://calendar.google.com/calendar/embed?src=ms6efr2erlvum9aolnvg1688cd3mu85e%40import.calendar.google.com&ctz=America%2FNew_York)
or you can subscribe to the iCal feed [here](https://app.opsgenie.com/webcal/getRecentSchedule?webcalToken=75f2990470ca21de1033ecf4586bea1e40bae32bf3c39e2289f6186da1904ee0&scheduleId=a3505963-c064-4c97-8865-947dfcb06060)

## Cutting a release

* We do releases every 3 months, at the end of each quarter, as described in the
  [release schedule](RELEASES.md#release-schedule).
* Take a look at open issues tagged with the current release, by
  [searching](https://github.com/envoyproxy/envoy/issues) for
  "is:open is:issue milestone:[current milestone]" and either hold off until
  they are fixed or bump them to the next milestone.
* Begin marshalling the ongoing PR flow in this repo. Ask maintainers to hold off merging any
  particularly risky PRs until after the release is tagged. This is because we aim for master to be
  at release candidate quality at all times.
* Do a final check of the [release notes](docs/root/intro/version_history.rst):
  * Make any needed corrections (grammar, punctuation, formatting, etc.).
  * Check to see if any security/stable version release notes are duplicated in
    the major version release notes. These should not be duplicated.
  * Remove the "Pending" tags and add dates to the top of the [release notes](docs/root/intro/version_history.rst)
    and [deprecated log](docs/root/intro/deprecated.rst).
  * Switch the [VERSION](VERSION) from a "dev" variant to a final variant. E.g., "1.6.0-dev" to
    "1.6.0".
  * Get a review and merge.
* Create a [tagged release](https://github.com/envoyproxy/envoy/releases). The release should
  start with "v" and be followed by the version number. E.g., "v1.6.0". **This must match the
  [VERSION](VERSION).**
* Create a branch from the tagged release, e.g. "release/v1.6". It will be used for the
  [stable releases](RELEASES.md#stable-releases).
* Monitor the CircleCI tag build to make sure that the final docker images get pushed along with
  the final docs. The final documentation will end up in the
  [envoyproxy.github.io repository](https://github.com/envoyproxy/envoyproxy.github.io/tree/master/docs/envoy).
* Contact rdl@ on Slack so that the website can be updated for the new release.
* Craft a witty/uplifting email and send it to all the email aliases including envoy-announce@.
* If possible post on Twitter (either have Matt do it or contact caniszczyk@ on Slack and have the
  Envoy account post).
* Do a new PR to update [VERSION](VERSION) to the next development release. E.g., "1.7.0-dev". At
  the same time, also add a new empty "pending" section to the [release
  notes](docs/root/intro/version_history.rst) and to [deprecated log](docs/root/intro/deprecated.rst) for the
  following version. E.g., "1.7.0 (pending)".
* Run the deprecate_versions.py script (e.g. `sh tools/deprecate_version/deprecate_version.sh`)
  to file tracking issues for code which can be removed.
* Run the deprecate_features.py script (e.g. `sh tools/deprecate_features/deprecate_features.sh`)
  to make the last release's deprecated features fatal-by-default. Submit the resultant PR and send
  an email to envoy-announce.
* Check source/common/runtime/runtime_features.cc and see if any runtime guards in
  disabled_runtime_features should be reassessed, and ping on the relevant issues.

## When does a maintainer lose maintainer status

If a maintainer is no longer interested or cannot perform the maintainer duties listed above, they
should volunteer to be moved to emeritus status. In extreme cases this can also occur by a vote of
the maintainers per the voting process below.

# Extension addition policy

Adding new [extensions](REPO_LAYOUT.md#sourceextensions-layout) has a dedicated policy. Please
see [this](./EXTENSION_POLICY.md) document for more information.

# Conflict resolution and voting

In general, we prefer that technical issues and maintainer membership are amicably worked out
between the persons involved. If a dispute cannot be decided independently, the maintainers can be
called in to decide an issue. If the maintainers themselves cannot decide an issue, the issue will
be resolved by voting. The voting process is a simple majority in which each senior maintainer
receives two votes and each normal maintainer receives one vote.

# Adding new projects to the envoyproxy GitHub organization

New projects will be added to the envoyproxy organization via GitHub issue discussion in one of the
existing projects in the organization. Once sufficient discussion has taken place (~3-5 business
days but depending on the volume of conversation), the maintainers of *the project where the issue
was opened* (since different projects in the organization may have different maintainers) will
decide whether the new project should be added. See the section above on voting if the maintainers
cannot easily decide.

packyzbq/istio-envoy

简介

发行版

贡献者

近期动态

packyzbq/istio-envoy .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

packyzbq/istio-envoy