New submit repo for hotspot changes

Roman Kennke rkennke at
Tue Mar 13 15:48:32 UTC 2018

Hi Jesper and all,

this is very great news! Thank you!

I have questions:
- In case of a failure, that is not obviously related (probably spurious
unrelated test failure), is it possible to re-submit a test job? And how?
- Related to this, how would a new revision of a change be submitted? Do
the change in the same branch and push? Would that be picked up and

Thanks, Roman

> Hi all HotSpot developers!
> There is now a new submit repo available. It is similar to the one created a while ago [1], and the usage is the same, but this one is based on and synched with the jdk/hs forest. This means that it should now be possible for any contributor to run all the required tests for hotspot pushes (referred to as hs tier 1) on the latest version of the HotSpot source code.
> The results will still be returned in a mail with limited usage in case of a failure, but if all tests pass (and you fulfill the other criteria below) you will be ready to push your change. We do no longer require an Oracle sponsor to push changes to HotSpot.
> The following is not new, but I list it here for completeness.
> In order to push a change to HotSpot:
> 0. you must be a Committer in the JDK project.
> 1. you need a JBS issue for tracking.
> 2. your change must have been available for review at least 24 hours.
> 3. your change must have been approved by two Committers out of which at least one is also a Reviewer.
> 4. your change must have passed through the hs tier 1 testing provided by the submit-hs repository with zero failures.
> 5. 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.
> 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 5 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".
> 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.
> One of these days I'll figure out how to put this stuff on the OpenJDK wiki.
> Thanks,
> /Jesper
> [1]

More information about the jdk-dev mailing list