HHH-17794 Updated CONTRIBUTING guide
Updated Jira Pull Request Handling and cleaned up some grammer issues.
This commit is contained in:
parent
955b587eb7
commit
f4d9bed845
|
@ -1,6 +1,6 @@
|
|||
# Contributing
|
||||
|
||||
Contributions from the community are essential in keeping Hibernate (any Open Source
|
||||
Contributions from the community are essential in keeping Hibernate (and any Open Source
|
||||
project really) strong and successful.
|
||||
|
||||
# Legal
|
||||
|
@ -8,11 +8,13 @@ project really) strong and successful.
|
|||
All original contributions to Hibernate are licensed under the
|
||||
[GNU Lesser General Public License (LGPL)](https://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt),
|
||||
version 2.1 or later, or, if another license is specified as governing the file or directory being
|
||||
modified, such other license. The LGPL text is included verbatim in the [lgpl.txt](lgpl.txt) file
|
||||
in the root directory of the ORM repository.
|
||||
modified, such other license.
|
||||
|
||||
The LGPL text is included verbatim in the [lgpl.txt](lgpl.txt) file in the root directory of the ORM repository.
|
||||
|
||||
All contributions are subject to the [Developer Certificate of Origin (DCO)](https://developercertificate.org/).
|
||||
The DCO text is also included verbatim in the [dco.txt](dco.txt) file in the root directory of the ORM repository.
|
||||
|
||||
The DCO text is available verbatim in the [dco.txt](dco.txt) file in the root directory of the ORM repository.
|
||||
|
||||
|
||||
## Guidelines
|
||||
|
@ -21,33 +23,35 @@ While we try to keep requirements for contributing to a minimum, there are a few
|
|||
we ask that you mind.
|
||||
|
||||
For code contributions, these guidelines include:
|
||||
* respect the project code style - find templates for [IntelliJ IDEA](https://hibernate.org/community/contribute/intellij-idea/) or [Eclipse](https://hibernate.org/community/contribute/eclipse-ide/)
|
||||
* have a corresponding JIRA issue and the key for this JIRA issue should be used in the commit message
|
||||
* have a set of appropriate tests. For bug reports, the tests reproduce the initial reported bug
|
||||
and illustrate that the solution actually fixes the bug. For features/enhancements, the
|
||||
tests illustrate the feature working as intended. In both cases the tests are incorporated into
|
||||
the project to protect against regressions
|
||||
* if applicable, documentation is updated to reflect the introduced changes
|
||||
* the code compiles and the tests pass (`./gradlew clean build`)
|
||||
* Respect the project code style - find templates for [IntelliJ IDEA](https://hibernate.org/community/contribute/intellij-idea/) or [Eclipse](https://hibernate.org/community/contribute/eclipse-ide/)
|
||||
* Have a corresponding JIRA [issue](https://hibernate.atlassian.net/browse/HHH) and be sure to include the key for this JIRA issue in your commit messages.
|
||||
* Have a set of appropriate tests.
|
||||
For your convenience, a [set of test templates](https://github.com/hibernate/hibernate-test-case-templates/tree/main/orm) have been made available.
|
||||
|
||||
When submitting bug reports, the tests should reproduce the initially reported bug and illustrate that your solution addresses the issue.
|
||||
For features/enhancements, the tests should demonstrated that the feature works as intended.
|
||||
In both cases, be sure to incorporate your tests into the project to protect against possible regressions.
|
||||
* If applicable, documentation should be updated to reflect the introduced changes
|
||||
* The code compiles and the tests pass (`./gradlew clean build`)
|
||||
|
||||
For documentation contributions, mainly just respect the project code style, especially in regards
|
||||
to use of tabs - as mentioned above, code style templates are available for both IntelliJ IDEA and Eclipse
|
||||
IDEs. Ideally these contributions would also have a corresponding JIRA issue, although this
|
||||
For documentation contributions, mainly to respect the project code style, especially in regards
|
||||
to the use of tabs - as mentioned above, code style templates are available for both IntelliJ IDEA and Eclipse
|
||||
IDEs. Ideally, these contributions would also have a corresponding JIRA issue, although this
|
||||
is less necessary for documentation contributions.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
If you are just getting started with Git, GitHub and/or contributing to Hibernate via
|
||||
If you are just getting started with Git, GitHub, and/or contributing to Hibernate via
|
||||
GitHub there are a few pre-requisite steps to follow:
|
||||
|
||||
* make sure you have a [Hibernate JIRA account](https://hibernate.atlassian.net)
|
||||
* make sure you have a [GitHub account](https://github.com/signup/free)
|
||||
* [fork](https://help.github.com/articles/fork-a-repo) the Hibernate repository. As discussed in
|
||||
* Make sure you have a [Hibernate JIRA account](https://hibernate.atlassian.net)
|
||||
* Make sure you have a [GitHub account](https://github.com/signup/free)
|
||||
* [Fork](https://help.github.com/articles/fork-a-repo) the Hibernate repository. As discussed in
|
||||
the linked page, this also includes:
|
||||
* [set up your local git install](https://help.github.com/articles/set-up-git)
|
||||
* clone your fork
|
||||
* see the wiki pages for setting up your IDE, whether you use
|
||||
* See the wiki pages for setting up your IDE, whether you use
|
||||
[IntelliJ IDEA](https://hibernate.org/community/contribute/intellij-idea/)
|
||||
or [Eclipse](https://hibernate.org/community/contribute/eclipse-ide/)<sup>(1)</sup>.
|
||||
|
||||
|
@ -57,8 +61,8 @@ or [Eclipse](https://hibernate.org/community/contribute/eclipse-ide/)<sup>(1)</s
|
|||
Create a [topic branch](https://git-scm.com/book/en/Git-Branching-Branching-Workflows#Topic-Branches)
|
||||
on which you will work. The convention is to incorporate the JIRA issue key in the name of this branch,
|
||||
although this is more of a mnemonic strategy than a hard-and-fast rule - but doing so helps:
|
||||
* remember what each branch is for
|
||||
* isolate the work from other contributions you may be working on
|
||||
* Remember what each branch is for
|
||||
* Isolate the work from other contributions you may be working on
|
||||
|
||||
_If there is not already a JIRA issue covering the work you want to do, create one._
|
||||
|
||||
|
@ -73,27 +77,26 @@ Do your thing!
|
|||
|
||||
## Commit
|
||||
|
||||
* make commits of logical units
|
||||
* be sure to **use the JIRA issue key** in the commit message. This is how JIRA will pick
|
||||
* Make commits of logical units
|
||||
* Be sure to **use the JIRA issue key** in the commit message. This is how JIRA will pick
|
||||
up the related commits and display them on the JIRA issue
|
||||
* make sure you have added the necessary tests for your changes
|
||||
* run _all_ the tests to assure nothing else was accidentally broken
|
||||
* make sure your source does not violate the _checkstyles_
|
||||
* Make sure you have added the necessary tests for your changes
|
||||
* Run _all_ the tests to ensure nothing else was accidentally broken
|
||||
* Make sure your source does not violate the _checkstyles_
|
||||
|
||||
_Prior to committing, if you want to pull in the latest upstream changes (highly
|
||||
_Before committing, if you want to pull in the latest upstream changes (highly
|
||||
appreciated btw), please use rebasing rather than merging. Merging creates
|
||||
"merge commits" that really muck up the project timeline._
|
||||
"merge commits" that invariably muck up the project timeline._
|
||||
|
||||
## Submit
|
||||
|
||||
* push your changes to the topic branch in your fork of the repository
|
||||
* initiate a [pull request](https://help.github.com/articles/creating-a-pull-request)
|
||||
* update the JIRA issue by providing the PR link in the **Pull Request** column on the right
|
||||
|
||||
* Push your changes to the topic branch in your fork of the repository
|
||||
* Initiate a [pull request](https://help.github.com/articles/creating-a-pull-request)
|
||||
* Once your pull request has been summitted you can verify that the pull request has been properly linked to its corrosponding Jira issue by clicking on the _Recent rule runs_ _Refresh_ button on the right side of issue, if your pull request has been properly linked a _Pull Request (ORM)_ entry will be displayed.
|
||||
|
||||
It is important that this topic branch on your fork:
|
||||
|
||||
* be isolated to just the work on this one JIRA issue, or multiple issues if they are
|
||||
* Is isolated to just the work on this one JIRA issue, or multiple issues if they are
|
||||
related and also fixed/implemented by this work. The main point is to not push
|
||||
commits for more than one PR to a single branch - GitHub PRs are linked to
|
||||
a branch rather than specific commits
|
||||
|
|
Loading…
Reference in New Issue