rubygems-update 2.6.1 → 3.5.0

data/CODE_OF_CONDUCT.md

@@ -1,40 +1,81 @@
-# Contributor Code of Conduct
+# RubyGems and Bundler Code of Conduct
 
-As contributors and maintainers of this project, and in the interest of
-fostering an open and welcoming community, we pledge to respect all people who
-contribute through reporting issues, posting feature requests, updating
-documentation, submitting pull requests or patches, and other activities.
+## Our Pledge
 
-We are committed to making participation in this project a harassment-free
-experience for everyone, regardless of level of experience, gender, gender
-identity and expression, sexual orientation, disability, personal appearance,
-body size, race, ethnicity, age, religion, or nationality.
+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.
 
-Examples of unacceptable behavior by participants include:
+We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
 
-* The use of sexualized language or imagery
-* Personal attacks
-* Trolling or insulting/derogatory comments
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our community include:
+
+* 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 include:
+
+* 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 other's private information, such as physical or electronic
-  addresses, without explicit permission
-* Other unethical or unprofessional conduct.
-
-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. By adopting this Code of Conduct,
-project maintainers commit themselves to fairly and consistently applying these
-principles to every aspect of managing this project. Project maintainers who do
-not follow or enforce the Code of Conduct may be permanently removed from the
-project team.
-
-This code of conduct applies both within project spaces and in public spaces
-when an individual is representing the project or its community.
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by opening an issue or contacting one or more of the project
-maintainers.
-
-This Code of Conduct is adapted from the [Contributor
-Covenant](http://contributor-covenant.org), version 1.2.0, available at
-[http://contributor-covenant.org/version/1/2/0/](http://contributor-covenant.org/version/1/2/0/)
+* 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
+
+## Enforcement Responsibilities
+
+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.
+
+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 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 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.
+
+**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 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

@@ -0,0 +1,231 @@
+# How to contribute
+
+Community involvement is essential to RubyGems. We want to keep it as easy as
+possible to contribute changes. There are a few guidelines that we need
+contributors to follow to reduce the time it takes to get changes merged in.
+
+## Guidelines
+
+1.  New features should be coupled with tests.
+
+2.  Ensure that your code blends well with ours:
+    *   No trailing whitespace
+    *   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`
+
+4.  Don't modify the history file or version number.
+
+5.  If you have any questions, Feel free to join us on Slack, you can register
+    by signing up at http://slack.bundler.io or file an issue here:
+    http://github.com/rubygems/rubygems/issues
+
+
+For more information and ideas on how to contribute to RubyGems ecosystem, see
+here: https://guides.rubygems.org/contributing/
+
+## Getting Started
+
+### Installing dependencies
+
+    rake setup
+
+> **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 exe/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:
+
+    rake spec:parallel_deps
+
+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
+
+RubyGems uses labels to track all issues and pull requests. In order to
+provide guidance to the community this is documentation of how labels are used
+in the rubygems repository.
+
+### Contribution
+
+These labels are made to guide contributors to issue/pull requests that they
+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
+
+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.
+*   **feature request** - An issue describing a request for a new feature or
+    enhancement.
+*   **question** - An issue that is a more of a question than a call for
+    specific changes in the codebase.
+*   **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
+
+The light yellow `status: *` labels that indicate the state of an  issue,
+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 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 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
+*   **blocked / backlog** - the issue/pull request is currently unable to move
+    forward because of some specific reason, generally this will be a reason
+    that is outside RubyGems or needs feedback from some specific individual
+    or group, and it may be a while before something it is resolved.
+
+
+### Closed Reason
+
+Reasons are why an issue / pull request was closed without being worked on or
+accepted. There should also be more detailed information in the comments. The
+closed reason labels are maroon `closed: *`.
+
+*   **duplicate** - This is a duplicate of an existing bug. The comments must
+    reference the existing issue.
+*   **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.
+*   **deprecated** - An issue/pull request that no longer applies to the
+    actively maintained codebase.
+*   **discussion** - An issue/pull that is no longer about a concrete change,
+    and is instead being used for discussion.
+
+
+### Categories
+
+These are aspects of the codebase, or what general area the issue or pull
+request pertains too. Not all issues will have a category. All categorized
+issues have a blue `category: *` label.
+
+*   **gemspec** - related to the gem specification itself
+*   **API** - related to the public supported rubygems API. This is the code
+    API, not a network related API.
+*   **command** - related to something in `Gem::Commands`
+*   **install** - related to gem installations
+*   **documentation** - related to updating / fixing / clarifying
+    documentation or guides
+
+
+### Platforms
+
+If an issue or pull request pertains to only one platform, then it should have
+an appropriate purple `platform: *` label. Current platform labels:
+**windows**, **java**, **osx**, **linux**
+
+### Git
+
+Please sign your commits. Although not required in order for you to contribute,
+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.
+
+Please see https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work or
+https://help.github.com/en/articles/signing-commits for details on how to
+to generate a signature and automatically sign your commits.

data/MAINTAINERS.txt

@@ -0,0 +1,8 @@
+Luis Sagastume <lsagastume1990@gmail.com> (@bronzdoc)
+Daniel Berger <djberg96@gmail.com> (@djberg96)
+Ellen Marie Dash <me@duckie.co> (@duckinator)
+Evan Phoenix <evan@phx.io> (@evanphx)
+SHIBATA Hiroshi <hsbt@ruby-lang.org> (@hsbt)
+André Arko <andre@arko.net> (@indirect)
+Samuel Giddins <segiddins@segiddins.me> (@segiddins)
+David Rodríguez <deivid.rodriguez@riseup.net> (@deivid-rodriguez)