In order to push a change to the HotSpot source code you need to complete all the steps in the list below. This is done in order to ensure code quality and reduce the risk of introducing bugs into the code base.
- You must be a Committer in the JDK project
- You need a JBS issue for tracking
- Your change must have been available for review at least 24 hours
- Your change must have been approved by two Committers out of which at least one is also a Reviewer
- Your change must have passed through the hs tier 1 testing provided by the submit-hs repository with zero failures
- 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
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.
Pushing a change is fairly straight forward. Make sure your commit has a proper description. The JBS bug id and the Rewiewed-by lines are mandatory.
Always make sure there are no new changes in the repository you are pushing to before pushing
hg in should return an empty set of changes when you push. Always verify this the last thing you do! If there are new changes in there you must pull these changes and rebase your patch on top of these new changes. We use rebase to avoid merge changesets as we want to keep the mercurial history as linear as possible. This makes it easier to do binary searches through the history when trying to determine the cause of some changed behavior for instance (read debugging).
hg pull -u --rebase
Look through the new changes before you push your change. Did something recently pushed conflict with your change? There may be a need to rerun some testing or at least recompile before pushing.
When you feel confident enough, push using
As noted in the list above, you are expected to be around after having pushed a change in case there are any issues with it. 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 #6 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".