Hibernate
/
hibernate-orm
mirror of https://github.com/hibernate/hibernate-orm
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

HHH-17794 Updated CONTRIBUTING guide 

Updated Jira Pull Request Handling and cleaned up some grammer issues.
This commit is contained in:
Jeff Maxwell 2024-03-01 18:10:19 -06:00 committed by Christian Beikov
parent 955b587eb7
commit f4d9bed845
1 changed files with 37 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

71
CONTRIBUTING.md
View File

@ -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