Page History

...

1. You must be a Committer in the JDK project
2. You need a JBS issue for tracking
3. Your change must have been available for review at least 24 hours
4. Your change must have been approved by two Committers out of which at least one is also a Reviewer
5. Your change must have passed through the hs tier 1 testing provided by the submit-hs repository with zero failures
6. You must run all relevant testing to make sure your actual change is working
7. You must be available the next few hours, and the next day and ready to follow up with any fix needed in case your change causes problems in later tiers

There is a notion of trivial changes that can be pushed sooner than 24 hours. It should be clearly stated in the review mail that the intention is to push as a trivial change. How to actually define "trivial" is decided on a case-by-case basis but in general it would be things like fixing a comment, or moving code without changing it. Backing out a change is also considered trivial as the change itself in that case is generated by mercurial.

Relevant testing

Please note that the submit repository will only run a set of smoke-tests to ensure your change compiles and runs on a variety of platforms. It will not do any targeted testing on the particular code you have changed. Running through the submit repository is only the minimum requirement. You must also make sure your change works as expected before pushing using targeted testing. Consider writing a few JTREG tests for your change, or some unit tests using the GTest framework. Including the new tests (in the right places) with your push to the submit repository will ensure your tests will be run as part of your testing on all platforms and in the future. Look for tier1 in test/hotspot/jtreg/TEST.groups to see which tests and directories that are included in the submit repo testing. If you have larger tests that may not be suitable as tier1 tests in the final push, you can still include the tests in your submit repository run to get them executed on all platforms.

The push

Pushing a change is fairly straight forward. Make sure your commit has a proper description. The JBS bug id and the Rewiewed-by lines are mandatory.

...

As noted in the list above, you are expected to be around after having pushed a change in case there are any issues with it. A change that causes failures in later tiers may be backed out if a fix can not be provided fast enough, or if the developer is not responsive when noticed about the failure. Note that #6 #7 above should be interpreted as "it is a really bad idea to push a change the last thing you do before bedtime, or the day before going on vacation".

...