New submit repo for hotspot changes

[Lindenmaier, Goetz]

Hi

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,
  Goetz.

> -----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 [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