mirror of
https://github.com/saltstack/salt.git
synced 2025-04-17 10:10:20 +00:00
Fix pre-commit errors
This commit is contained in:
Alyssa Rock
Daniel Wozniak
parent
5685dbe708
commit
99b074b081
1 changed files with 106 additions and 104 deletions
210
POLICY.rst
210
POLICY.rst
|
|
@ -1,104 +1,106 @@
|
||||||
=================================
|
=================================
|
||||||
Salt Project maintenance policies
|
Salt Project maintenance policies
|
||||||
=================================
|
=================================
|
||||||
|
|
||||||
This document explains the current project maintenance policies. The goal of
|
This document explains the current project maintenance policies. The goal of
|
||||||
these policies are to reduce the maintenance burden on core maintainers of the
|
these policies are to reduce the maintenance burden on core maintainers of the
|
||||||
Salt Project and to encourage more active engagement from the Salt community.
|
Salt Project and to encourage more active engagement from the Salt community.
|
||||||
|
|
||||||
* `Issue management`_
|
* `Issue management`_
|
||||||
* `Pull request management`_
|
* `Pull request management`_
|
||||||
* `Salt Enhancement Proposals (SEP) process`_
|
* `Salt Enhancement Proposals (SEP) process`_
|
||||||
|
|
||||||
|
|
||||||
Issue management
|
Issue management
|
||||||
================
|
================
|
||||||
Issues for the Salt Project are critical to Salt community communication and to
|
Issues for the Salt Project are critical to Salt community communication and to
|
||||||
find and resolve issues in the Salt Project. As such, the issue tracker needs to
|
find and resolve issues in the Salt Project. As such, the issue tracker needs to
|
||||||
be kept clean and current to the currently supported releases of Salt. They also
|
be kept clean and current to the currently supported releases of Salt. They also
|
||||||
need to be free of feature requests, arguments, and trolling.
|
need to be free of feature requests, arguments, and trolling.
|
||||||
|
|
||||||
We have decided to update our issue policy to be similar to RedHat community
|
We have decided to update our issue policy to be similar to RedHat community
|
||||||
project policies.
|
project policies.
|
||||||
|
|
||||||
Community members who repeatedly violate these policies are subject to bans.
|
Community members who repeatedly violate these policies are subject to bans.
|
||||||
|
|
||||||
#. All issues that were not opened against a currently supported release of Salt
|
#. All issues that were not opened against a currently supported release of Salt
|
||||||
will be closed.
|
will be closed.
|
||||||
|
|
||||||
- When an old release of Salt is marked out of support, all issues opened
|
- When an old release of Salt is marked out of support, all issues opened
|
||||||
against the now defunct release will be closed.
|
against the now defunct release will be closed.
|
||||||
- If the issue is still present in the current release of Salt, submit a new
|
- If the issue is still present in the current release of Salt, submit a new
|
||||||
issue. Do not re-open the old issue after it has been closed.
|
issue. Do not re-open the old issue after it has been closed.
|
||||||
- When opening a new issue that was a bug in a previous release of Salt, you
|
- When opening a new issue that was a bug in a previous release of Salt, you
|
||||||
must validate it against a currently supported release of Salt for
|
must validate it against a currently supported release of Salt for
|
||||||
consideration. Issues that do not show the problem against a current
|
consideration. Issues that do not show the problem against a current
|
||||||
release will be closed without consideration.
|
release will be closed without consideration.
|
||||||
#. Only defects can be submitted to the issue tracker.
|
|
||||||
|
#. Only defects can be submitted to the issue tracker.
|
||||||
- Feature requests without a PR will be immediately closed.
|
|
||||||
- Feature requests must be designated as a feature being developed and owned
|
- Feature requests without a PR will be immediately closed.
|
||||||
by the issue submitter and assigned to a release. Otherwise they will be
|
- Feature requests must be designated as a feature being developed and owned
|
||||||
immediately closed.
|
by the issue submitter and assigned to a release. Otherwise they will be
|
||||||
- Discussions about features can be held in the GitHub
|
immediately closed.
|
||||||
`Discussions <https://github.com/saltstack/salt/discussions>`_ tab or in
|
- Discussions about features can be held in the GitHub
|
||||||
the community `Open Hour <https://saltproject.io/calendar/>`_.
|
`Discussions <https://github.com/saltstack/salt/discussions>`_ tab or in
|
||||||
- Questions will be immediately closed.
|
the community `Open Hour <https://saltproject.io/calendar/>`_.
|
||||||
#. Issues must submit sufficient information.
|
- Questions will be immediately closed.
|
||||||
|
|
||||||
- Issues must follow the relevant template for information.
|
#. Issues must submit sufficient information.
|
||||||
- Issues that do not give sufficient information about the nature of the
|
|
||||||
issue will be immediately closed.
|
- Issues must follow the relevant template for information.
|
||||||
- Issues that do not comply will be immediately closed.
|
- Issues that do not give sufficient information about the nature of the
|
||||||
|
issue will be immediately closed.
|
||||||
|
- Issues that do not comply will be immediately closed.
|
||||||
Pull request management
|
|
||||||
=======================
|
|
||||||
The Salt pull request (PR) queue has been a challenge to maintain for the entire
|
Pull request management
|
||||||
life of the project. This is in large part due to the incredibly active and
|
=======================
|
||||||
vibrant community around Salt.
|
The Salt pull request (PR) queue has been a challenge to maintain for the entire
|
||||||
|
life of the project. This is in large part due to the incredibly active and
|
||||||
Unfortunately, it has proven to be too much for the core team and the greater
|
vibrant community around Salt.
|
||||||
Salt community to manage. As such, we deem it necessary to make fundamental
|
|
||||||
changes to how we manage the PR queue:
|
Unfortunately, it has proven to be too much for the core team and the greater
|
||||||
|
Salt community to manage. As such, we deem it necessary to make fundamental
|
||||||
#. All PRs opened against releases of Salt that are no longer supported will be
|
changes to how we manage the PR queue:
|
||||||
closed immediately.
|
|
||||||
#. Closed PRs can be resubmitted, NOT re-opened.
|
#. All PRs opened against releases of Salt that are no longer supported will be
|
||||||
#. PRs need to provide full tests for all of the code affected, regardless of
|
closed immediately.
|
||||||
whether the PR author wrote the code affected.
|
#. Closed PRs can be resubmitted, NOT re-opened.
|
||||||
#. PR tests need to be written using the current test mechanism (pytest).
|
#. PRs need to provide full tests for all of the code affected, regardless of
|
||||||
#. PRs need to pass tests.
|
whether the PR author wrote the code affected.
|
||||||
#. PRs must NOT increase the overall test time by a noticeable length.
|
#. PR tests need to be written using the current test mechanism (pytest).
|
||||||
#. PRs must NOT add new plugins directly to Salt unless sanctioned by the Salt
|
#. PRs need to pass tests.
|
||||||
core team. New plugins should be made into Salt Extensions.
|
#. PRs must NOT increase the overall test time by a noticeable length.
|
||||||
#. PRs that have not been updated due to inactivity will be closed. Inactivity
|
#. PRs must NOT add new plugins directly to Salt unless sanctioned by the Salt
|
||||||
is determined by a lack of submitter activity for the space of 1 month.
|
core team. New plugins should be made into Salt Extensions.
|
||||||
#. PR tests should always maintain or increase total code coverage.
|
#. PRs that have not been updated due to inactivity will be closed. Inactivity
|
||||||
|
is determined by a lack of submitter activity for the space of 1 month.
|
||||||
|
#. PR tests should always maintain or increase total code coverage.
|
||||||
Salt Enhancement Proposals (SEP) process
|
|
||||||
========================================
|
|
||||||
**A message from Thomas Hatch, creator of Salt:**
|
Salt Enhancement Proposals (SEP) process
|
||||||
|
========================================
|
||||||
In 2019, we decided to create a community process to discuss and review Salt
|
**A message from Thomas Hatch, creator of Salt:**
|
||||||
Enhancement Proposals (SEPs). Unfortunately, I feel that this process has not
|
|
||||||
proven to be an effective way to solve the core issues around Salt Enhancements.
|
In 2019, we decided to create a community process to discuss and review Salt
|
||||||
Overall, the Salt enhancement process has proven itself to be more of a burden
|
Enhancement Proposals (SEPs). Unfortunately, I feel that this process has not
|
||||||
than an accelerant to Salt stability, security, and progress. As such, I feel
|
proven to be an effective way to solve the core issues around Salt Enhancements.
|
||||||
that the current optimal course of action is to shut the process down.
|
Overall, the Salt enhancement process has proven itself to be more of a burden
|
||||||
|
than an accelerant to Salt stability, security, and progress. As such, I feel
|
||||||
Instead of the Salt Enhancement Proposal process, we will add a time in the
|
that the current optimal course of action is to shut the process down.
|
||||||
`Open Hour <https://saltproject.io/calendar/>`_ for people to present ideas and
|
|
||||||
concepts to better understand if they are worth their effort to develop.
|
Instead of the Salt Enhancement Proposal process, we will add a time in the
|
||||||
Extensive documentation around more intrusive or involved enhancements should
|
`Open Hour <https://saltproject.io/calendar/>`_ for people to present ideas and
|
||||||
be included in pull requests (PRs). Conversations about enhancements can also be
|
concepts to better understand if they are worth their effort to develop.
|
||||||
held in the `Discussions <https://github.com/saltstack/salt/discussions>`_ tab
|
Extensive documentation around more intrusive or involved enhancements should
|
||||||
in GitHub.
|
be included in pull requests (PRs). Conversations about enhancements can also be
|
||||||
|
held in the `Discussions <https://github.com/saltstack/salt/discussions>`_ tab
|
||||||
By migrating the conversation into the PR process, we ensure that we are only
|
in GitHub.
|
||||||
reviewing viable proposals instead of being burdened with requests that the core
|
|
||||||
team is expected to fulfill.
|
By migrating the conversation into the PR process, we ensure that we are only
|
||||||
|
reviewing viable proposals instead of being burdened with requests that the core
|
||||||
Effective immediately (January 2024), we are archiving and freezing the SEP
|
team is expected to fulfill.
|
||||||
repo.
|
|
||||||
|
Effective immediately (January 2024), we are archiving and freezing the SEP
|
||||||
|
repo.
|
||||||
|
|
|
||||||
Loading…
Add table
Reference in a new issue