Skip to content

Commit 88df335

Browse files
committed
[doc] Save guide for writing java pull request
1 parent df776f1 commit 88df335

File tree

1 file changed

+19
-0
lines changed

1 file changed

+19
-0
lines changed

upstream/mailing.txt

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,19 @@
1+
TODO for future me (https://openjdk.java.net/contribute/)
2+
3+
3. Submit a patch
4+
5+
Your patch must be built and tested on all relevant platforms before submission. Refer to the appropriate release-specific build and test instructions for JDK (build, test) or JDK Updates (build, test). If you have problems building, you may send your questions to the Build Group's mailing list. Note that a full build against recently synchronized sources with only your applied patch is required for each submitted change.
6+
7+
When your change is ready, send a message to the appropriate development list with a subject line of the form
8+
9+
[PATCH] 6543210: My favorite bug
10+
11+
where 6543210 and My favorite bug are replaced as above. If no existing bug or RFE describes your change then omit the id number and one will be created and assigned.
12+
13+
The message should contain three things, either directly, or in the body as attachments:
14+
15+
A description of the change, including a rationale for your approach and a discussion of any alternative approaches that were considered, if relevant. If no existing bug or RFE describes your change then also include a description of the problem that it solves or the need that it addresses.
16+
17+
The code change itself, relative to an existing changeset in the appropriate Mercurial repository. The preferred form is generated by Mercurial's hg export command, with the -g option so that file renames are tracked correctly. The output of hg diff -g is also acceptable, and in the worst case traditional unified diffs (-u) are okay too, at least for simple changes.
18+
19+
A unit test, written for the jtreg test harness, that validates your change. The test should fail when run against a build without the change and succeed when run against a build with the change. Unit tests aren't always practical, especially for changes such as performance improvements or fixes to bugs that are highly platform-dependent, but if practical then a unit test is required.

0 commit comments

Comments
 (0)