rubygems-update 3.1.6 → 3.4.10

data/CODE_OF_CONDUCT.md

@@ -1,45 +1,81 @@
-# Contributor Code of Conduct
+# RubyGems and Bundler Code of Conduct
 
 ## Our Pledge
 
-In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making 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, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
+We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
 
 ## Our Standards
 
-Examples of behavior that contributes to creating a positive environment include:
+Examples of behavior that contributes to a positive environment for our community 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
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the overall community
 
-Examples of unacceptable behavior by participants include:
+Examples of unacceptable behavior include:
 
-* The use of sexualized language or imagery and unwelcome sexual attention or advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
+* The use of sexualized language or imagery, and sexual attention or advances of any kind
+* Trolling, insulting or 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
+* Publishing others' private information, such as a physical or email address, without their explicit permission
 * Other conduct which could reasonably be considered inappropriate in a professional setting
 
-## Our Responsibilities
+## Enforcement 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.
+Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
 
-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.
+Community leaders 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, and will communicate reasons for moderation decisions when appropriate.
 
 ## 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.
+This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
 
 ## Enforcement
 
-Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the [project team](MAINTAINERS.txt). All complaints will be reviewed and investigated and will result in a response that is deemed necessary and 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.
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at team@bundler.io, or directly contacting project team members via email or Slack. All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series of actions.
 
-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.
+**Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior,  harassment of an individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within the community.
 
 ## Attribution
 
-This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.0,
+available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
+
+Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity).
 
 [homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see the FAQ at
+https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.

data/CONTRIBUTING.md

@@ -13,7 +13,6 @@ contributors to follow to reduce the time it takes to get changes merged in.
     *   Match indentation (two spaces)
     *   Match coding style (run `rake rubocop`)
 
-
 3.  If any new files are added or existing files removed in a commit or PR,
     please update the `Manifest.txt` accordingly. This can be done by running
     `rake update_manifest`
@@ -30,21 +29,74 @@ here: https://guides.rubygems.org/contributing/
 
 ## Getting Started
 
-    $ rake setup
-    $ rake test
+### Installing dependencies
+
+    rake setup
 
-> Optional you can configure git hooks with: rake git_hooks
+> **NOTE**: If the above fails with permission related errors, you're most
+> likely using a global Ruby installation (like the one packaged by your OS),
+> which sets `GEM_HOME` to a location regular users can't write to. Consider
+> using a Ruby version manager like [RVM](https://github.com/rvm/rvm),
+> [rbenv](https://github.com/rbenv/rbenv),
+> [chruby](https://github.com/postmodern/chruby) or [asdf](https://github.com/asdf-vm/asdf-ruby). These will install Ruby to a
+> location regular users can write to, so you won't run into permission issues.
+> Alternatively, consider setting `GEM_HOME` environment variable to a writable
+> location with something like `export GEM_HOME=/tmp/rubygems.gems` and try
+> again.
+
+### Manually trying your local changes
 
 To run commands like `gem install` from the repo:
 
-    $ ruby -Ilib bin/gem install
+    ruby -Ilib bin/gem install
+
+To run commands like `bundle install` from the repo:
+
+    ruby bundler/spec/support/bundle.rb install
+
+### Running Tests
+
+To run the entire test suite you can use:
+
+    rake test
+
+To run an individual test file located for example in `test/rubygems/test_deprecate.rb` you can use:
+
+    ruby -Ilib:test:bundler/lib test/rubygems/test_deprecate.rb
+
+And to run an individual test method named `test_default` within a test file, you can use:
+
+    ruby -Ilib:test:bundler/lib test/rubygems/test_deprecate.rb -n /test_default/
+
+### Running bundler tests
+
+Everything needs to be run from the `bundler/` subfolder.
+
+To setup bundler tests:
 
-To run bundler test:
+    rake spec:parallel_deps
 
-    $ cd bundler
-    $ git submodule update --init --recursive
-    $ bin/rake spec:deps
-    $ bin/rspec spec
+To run the entire bundler test suite in parallel (it takes a while):
+
+    bin/parallel_rspec
+
+There are some realworld higher level specs run in CI, but not run by `bin/parallel_rspec`. You can run those with:
+
+    bin/rake spec:realworld
+
+To run an individual test file location for example in `spec/install/gems/standalone_spec.rb` you can use:
+
+    bin/rspec spec/install/gems/standalone_spec.rb
+
+### Checking code style
+
+You can check compliance with our code style with
+
+    rake rubocop
+
+Optionally you can configure git hooks with to check this before every commit with
+
+    rake git_hooks
 
 ## Issues
 
@@ -55,37 +107,55 @@ in the rubygems repository.
 ### Contribution
 
 These labels are made to guide contributors to issue/pull requests that they
-can help with. That are marked with a light gray `contribution: *`
-
-*   **small** - The issue described here will take a small amount of work to
-    resolve, and is a good option for a new contributor
-*   **unclaimed** - The issue has not been claimed for work, and is awaiting
+can help with.
+
+*   **good first issue** - The issue described here is considered a good option
+    for a new contributor. We encourage new contributors though to work on
+    whichever issue they find most interesting, the ones labeled here as just
+    estimated to have a reasonable level of complexity for someone new to the
+    code base.
+*   **help wanted** - The issue has not been claimed for work, and is awaiting
     willing volunteers!
 
 
 ### Type
 
-Most Issues or pull requests will have a light green `type: *` label,  which
-describes the type of the issue or pull request.
+Issues might have a light green `type: *` label,  which describes the type of
+the issue.
 
 *   **bug report** - An issue describing a bug in rubygems. This would be
     something that is broken, confusing, unexpected behavior etc.
-*   **bug fix** - A pull request that fixes a bug report.
 *   **feature request** - An issue describing a request for a new feature or
     enhancement.
-*   **feature implementation** - A pull request implementing a feature
-    request.
 *   **question** - An issue that is a more of a question than a call for
     specific changes in the codebase.
-*   **cleanup** - Generally for a pull request that improves the code base
-    without fixing a bug or implementing a feature.
-*   **major bump** - This issue or pull request requires a major version bump
+*   **cleanup** - An issue that proposes cleanups to the code base without
+    fixing a bug or implementing a feature.
+*   **major bump** - This issue  request requires a major version bump
 *   **administrative** - This issue relates to administrative tasks that need
     to take place as it relates to rubygems
 *   **documentation** - This issue relates to improving the documentation for
     in this repo. Note that much of the rubygems documentation is here:
     https://github.com/rubygems/guides
 
+Pull request might have a light orange `rubygems: *` or a light blue `bundler:
+*` label which describes the pull request according to the following criteria:
+
+*   **security fix** - A pull request that fixes a security issue.
+*   **breaking change** - A pull request including any change that requires a
+    major version bump.
+*   **major enhancement** - A pull request including a backwards compatible
+    change worth a special mention in the changelog
+*   **deprecation** - A pull request that introduces a deprecation.
+*   **feature** - A pull request implementing a feature request.
+*   **deprecation** - A pull request that implements a performance improvement.
+*   **documentation** - A pull request introducing documentation improvements
+    worth mentioning to end users.
+*   **minor enhancements** - A pull request introducing small but user visible changes.
+*   **bug fix** - A pull request that fixes a bug report.
+
+In the case of `bundler`, these labels are set by maintainers on PRs and have
+special importance because they are used to automatically build the changelog.
 
 ### Workflow / Status
 
@@ -94,13 +164,13 @@ where it is in the process from being submitted to being closed.  These are
 listed in rough  progression order from submitted to closed.
 
 *   **triage** - This is an issue or pull request that needs to be properly
-    labeled by by a maintainer.
+    labeled by a maintainer.
 *   **confirmed** - This issue/pull request has been accepted as valid, but is
     not yet immediately ready for work.
 *   **ready** - An issue that is available for collaboration. This issue
     should have existing discussion on the problem, and a description of how
     to go about solving it.
-*   **working** - An issue that has a specific invidual assigned to and
+*   **working** - An issue that has a specific individual assigned to and
     planning to do work on it.
 *   **user feedback required** - The issue/pull request is blocked pending
     more feedback from an end user
@@ -118,7 +188,7 @@ closed reason labels are maroon `closed: *`.
 
 *   **duplicate** - This is a duplicate of an existing bug. The comments must
     reference the existing issue.
-*   **abandonded** - This is an issue/pull request that has aged off, is no
+*   **abandoned** - This is an issue/pull request that has aged off, is no
     longer applicable or similar.
 *   **declined** - An issue that won't be fixed/implemented or a pull request
     that is not accepted.
@@ -152,7 +222,7 @@ an appropriate purple `platform: *` label. Current platform labels:
 ### Git
 
 Please sign your commits. Although not required in order for you to contribute,
-it does ensures that any code submitted by you wasn't altered while you were
+it ensures that any code submitted by you wasn't altered while you were
 transferring it, and proves that it was you who submitted it and not someone
 else.