New submit repo for hotspot changes
jesper.wilhelmsson at oracle.com
jesper.wilhelmsson at oracle.com
Tue Mar 13 15:09:36 UTC 2018
There were several people involved in this decision. Iris Clark and Christian Törnqvist did the actual job, I did only send out the email. :-)
> On 13 Mar 2018, at 14:16, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> This is great I appreciate this quick progress a lot!!
> Thanks to Jesper and anybody else involved in enabling this.
> The rules make complete sense to me.
> Maybe simple build fixes should be considered as trivial, too.
> (Like adding missing #endif).
> Best regards,
>> -----Original Message-----
>> From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of
>> jesper.wilhelmsson at oracle.com
>> Sent: Dienstag, 13. März 2018 02:07
>> To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
>> Cc: jdk-dev <jdk-dev at openjdk.java.net>
>> Subject: New submit repo for hotspot changes
>> 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
>> 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
>> 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-
More information about the jdk-dev