New submit repo for hotspot changes

[Thomas Stüfe]

Thank you Jesper!

On Tue, Mar 13, 2018 at 4:02 PM, <jesper.wilhelmsson at oracle.com> wrote:

> The sync is done via an hg hook that pushes directly to the submit-hs repo
> as soon as anything enters hs, so it would be a matter of minutes at most.
> /Jesper
>
>
> On 13 Mar 2018, at 06:50, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>
> Hi Jesper,
>
> just a small question, how close will the syncing between submit-hs and
> jdk-hs be?
>
> Best Regards, Thomas
>
> 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 [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.
>>
>> http://hg.openjdk.java.net/jdk/submit-hs/
>>
>> 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] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/
>> 000566.html
>>
>>
>
>