New submit repo for hotspot changes
volker.simonis at gmail.com
Tue Mar 13 08:24:35 UTC 2018
that's really good news!
On Tue, Mar 13, 2018 at 2:06 AM, <jesper.wilhelmsson at oracle.com> wrote:
> Hi all HotSpot developers!
> There is now a new submit repo available. It is similar to the one created a while ago , 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.
>  http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000566.html
More information about the jdk-dev