You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+116-27
Original file line number
Diff line number
Diff line change
@@ -41,12 +41,19 @@ If you are a first time contributor to OpenJFX, welcome! Please do the following
41
41
42
42
* Sign the Contributor Agreement
43
43
44
-
In order for us to evaluate your contribution, you need to sign the [Oracle Contributor Agreement](https://www.oracle.com/technetwork/community/oca-486395.html) (OCA). Ultimately, the goal is to send accepted Pull Requests upstream to the OpenJFX repository hosted on openjdk.java.net. We are not asking you to give up your copyright, but to give us the right to distribute your code without restriction. By doing this you assert that the code you contribute is *yours* to contribute, and not third-party code that you do not own. We ask this of all contributors in order to assure our users of the origin and continuing existence of the code. You only need to sign the OCA once.
44
+
In order for us to evaluate your contribution, you need to sign the [Oracle Contributor Agreement](https://www.oracle.com/technetwork/community/oca-486395.html) (OCA). We are not asking you to give up your copyright, but to give us the right to distribute your code without restriction. By doing this you assert that the code you contribute is *yours* to contribute, and not third-party code that you do not own. We ask this of all contributors in order to assure our users of the origin and continuing existence of the code. You only need to sign the OCA once.
45
45
46
46
* Read the code review policies
47
47
48
48
Please read the entire section below on how to submit a pull request, as well as the [OpenJFX Code Review Policies](https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews). If this is a feature request, please note the additional requirements and expectations in the [New features / API additions](https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews#CodeReviews-NewFeaturesC.Newfeatures/APIadditions.) section of the Code Review Policies doc.
49
49
50
+
* File a bug in JBS for every pull request
51
+
52
+
A [JBS](https://bugs.openjdk.java.net) bug ID is needed for every
53
+
pull request. If there isn't already a bug filed in JBS, then please
54
+
file one at [bugreport.java.com](https://bugreport.java.com/).
55
+
A developer with an active OpenJDK ID can file a bug directly in JBS.
56
+
50
57
TIP: A GitHub pull request (PR) should not be the first time we hear about your proposed change to OpenJFX. Unless clearly identified as experimental or work-in-progress (WIP), we will usually close a pull request that isn't associated with an existing bug report. Reading the policies below will help you in getting your change approved.
51
58
52
59
### Submitting your changes via a pull request
@@ -61,39 +68,121 @@ Once your changes and tests are ready to submit for review:
61
68
62
69
Update your local repository with the most recent code from the main [repository]((https://github.com/openjdk/jfx)), and rebase your branch on top of the latest `master` branch. We prefer your initial changes to be squashed into a single commit. See the [GitHub help page](https://help.github.com/articles/about-git-rebase/) for help. Later, if we ask you to make changes, add them as separate commits. This makes them easier to review.
63
70
64
-
3. File a bug in JBS
65
-
66
-
If there isn't already a bug filed in [JBS](https://bugs.openjdk.java.net), then please file one at [bugreport.java.com](https://bugreport.java.com/). A JBS bug ID is needed even if you have already filed an issue in the GitHub issue tracker. A GitHub issue can be used as a convenience, but JBS is the official bug database for the OpenJFX Project. Once you submit a pull request, you can add an Issue link to the PR in the JBS bug. If you don't have direct JBS access, one of the Project Committers or Authors will do this for you.
67
-
68
-
4. Submit a pull request
71
+
3. Submit a pull request
69
72
70
-
Push your local changes to your forked copy of the repository and [submit a pull request](https://help.github.com/articles/using-pull-requests). In the pull request, choose a title which sums up the changes that you have made, and in the body provide more details about what your changes do. The title *should include a JBS Bug ID*, which will make it easier for reviewers to cross-reference your pull requests with JBS.
73
+
Push your local changes to your forked copy of the repository and
74
+
[submit a pull request](https://help.github.com/articles/using-pull-requests).
75
+
The title of the pull request must start with the 7-digit JBS bug id
76
+
(without the `JDK-` prefix), followed by a colon (`:`), then a space,
77
+
and finally the bug title as taken from JBS. You should include
78
+
additional details about your change in the Description of the pull
79
+
request. For example, the following is a valid pull request title:
71
80
72
-
5. Send an email requesting a code review
81
+
```
82
+
8231326: Update README and CONTRIBUTING docs for Skara
83
+
```
73
84
74
-
NOTE: Project Skara will automate the RFR email, so this step will likely be removed.
85
+
The Skara bot will then run `jcheck` on the server to verify the format
86
+
of the PR title and check for whitespace errors. Once that passes,
87
+
it will automatically send a Request For Review (RFR) email to the
It is the responsibility of the Reviewer(s) and the Committer who
120
+
will integrate the change to ensure that the code review policies
121
+
are followed, and that all concerns have been addressed.
122
+
123
+
Discussion and review of the pull request can happen either by adding
124
+
a comment to the PR itself, or by replying to the mailing list "RFR"
125
+
thread. The Skara bot will cross-forward between them.
126
+
To approve a pull request, a reviewer must do that in the PR itself.
127
+
See the following
128
+
[GitHub help page](https://help.github.com/en/articles/reviewing-proposed-changes-in-a-pull-request)
129
+
for help on reviewing a pull request.
130
+
131
+
If any changes
132
+
are needed, you would push additional commits to the branch
133
+
from which you made the pull request.
134
+
135
+
The code review continues until there are no unaddressed concerns, and
136
+
at least the minimum number of reviewers have approved the PR -- which
137
+
is one for low-impact bug fixes and two for enhancements or high-impact
138
+
bug fixes.
139
+
140
+
NOTE: while the Skara tooling will indicate that the PR is
141
+
ready to integrate once the first reviewer with a "Reviewer" role
142
+
in the project has approved it, this may or may not be sufficient
143
+
depending on the type of fix. For example, you must wait for a second
144
+
approval for enhancements or high-impact bug fixes.
145
+
146
+
5. Integrate the pull request
147
+
148
+
Once the review has completed as described above, you can integrate
149
+
the PR.
150
+
151
+
A. Verify the commit message. The Skara tooling adds a comment with
152
+
the commit message that will be used. You can add a summary to the
153
+
commit message with the `/summary` command. You can add additional
154
+
contributors with the `/contributor` command. Commands are issued
155
+
by adding a comment to the PR that starts with a slash `/` character.
156
+
157
+
B. Issue the `/integrate` command. If you have the "Committer" role
158
+
(or higher) in the Project, then the Skara bot will merge the change
159
+
with no further action on your part. If you are not a Committer,
160
+
then you must get a Committer to sponsor your change. This is often
161
+
one of the reviewers who reviewed your PR, but it need not be. The
162
+
sponsor will issue the `/sponsor` command after you issue `/integrate`
163
+
once they are satisfied that the review criteria have been met.
164
+
165
+
6. Resolve the JBS bug as "Fixed"
166
+
167
+
There is currently no automation for resolving JBS bugs, although
168
+
a future Skara improvement will automate this. Until then,
169
+
the Committer who integrated or sponsored the fix is responsible for
170
+
resolving the JBS issue. You do this with the "Resolve" action in JBS,
171
+
selecting "Fixed" as the resolution. You also need to add the commit
172
+
notification message (minus the list of modified files) as a comment.
173
+
This includes the URL of the commit. For example:
75
174
76
-
Send a Request For Review (RFR) email to the [openjfx-dev](mailto:[email protected]) mailing list. The email subject should include the JBS bug ID. The body of the review request should contain a pointer to the JBS issue and a pointer to the pull request. Here is an example RFR email:
Then sit back and wait. There will probably be discussion about the pull request and, if any changes are needed, we would love to work with you to get your pull request merged into OpenJFX.
183
+
Reviewed-by: ghb
184
+
```
86
185
87
-
Please adhere to the general guideline that you should never force push
88
-
to a publicly shared branch. Once you have opened your pull request, you
89
-
should consider your branch publicly shared. Instead of force pushing
90
-
you can just add incremental commits; this is generally easier on your
91
-
reviewers. If you need to pick up changes from `master`, you can merge
92
-
`master` into your branch. A reviewer might ask you to rebase a
93
-
long-running pull request in which case force pushing is okay for that
94
-
request. Note that squashing at the end of the review process should
95
-
also not be done, that will be done when the pull request is [integrated
96
-
via GitHub](https://github.com/blog/2141-squash-your-commits).
97
186
98
187
Contributing to the OpenJFX codebase
99
188
------------------------------------------
@@ -106,7 +195,7 @@ Currently OpenJFX builds are running on JDK 11 (recommended) and JDK 12.
106
195
It is possible to develop in any major Java IDE (Eclipse, IntelliJ, NetBeans). IDEs can automatically configure projects based on Gradle setup.
107
196
108
197
The following formatting rules are enforced for source code files by
109
-
the white-space checker that is run as part of our CI test builds:
198
+
`git jcheck`, which is run by the Skara bot:
110
199
111
200
* Use Unix-style (LF) line endings not DOS-style (CRLF)
112
201
* Do not use TAB characters (exception: Makefiles can have TABS)
Copy file name to clipboardExpand all lines: README.md
-2
Original file line number
Diff line number
Diff line change
@@ -10,8 +10,6 @@ OpenJFX is a project under the charter of the OpenJDK. The [OpenJDK Bylaws](http
10
10
11
11
If you think you have found a bug in OpenJFX, first make sure that you are testing against the latest version - your issue may already have been fixed. If not, search our [issues list](https://bugs.openjdk.java.net) in the Java Bug System (JBS) in case a similar issue has already been opened. More information on where and how to report a bug can be found at [bugreport.java.com](https://bugreport.java.com/).
12
12
13
-
Please note that while the issue tracker in this Github project can be a convenient place to file an issue (either a bug or an enhancement request), the official bug database for OpenJFX is [JBS](https://bugs.openjdk.java.net).
14
-
15
13
## Getting Started
16
14
17
15
For instructions on building JavaFX, see the [Building OpenJFX](https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX) Wiki page.
0 commit comments