New submit repo for hotspot changes
christian.tornqvist at oracle.com
Tue Mar 13 15:58:14 UTC 2018
> On Mar 13, 2018, at 11:48 32AM, Roman Kennke <rkennke at redhat.com> wrote:
> 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?
Easiest way is to just make a new change in the branch, I suggest pulling new changes in from the default branch every time you make changes to your branch as well. We can trigger a new build/test run but that requires help from someone inside of Oracle.
> - 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
Yes, it’ll monitor the branch and start building and testing for every change made in there. So you can re-use the same branch for multiple test runs.
> Thanks, Roman
>> 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 hotspot-dev