RFR: (T) 8241144 Javadoc is not generated for new module jdk.nio.mapmode
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Wed Mar 25 09:05:12 UTC 2020
On 2020-03-25 02:22, David Holmes wrote:
> On 25/03/2020 3:49 am, Florian Weimer wrote:
>> * Magnus Ihse Bursie:
>>> On 2020-03-24 09:59, Andrew Dinn wrote:
>>>> On 23/03/2020 18:38, Erik Joelsson wrote:
>>>>> Looks good.
>>>> Thanks for the review, Erik.
>>>> I'm assuming that also implies it is trivial (because, copyright
>>>> a side, it really is a 1-liner :-).
>>> For code in the build system, we do not have the Hotspot rules of
>>> multiple reviewers, waiting period or trtiviality. A single OK
>>> review is
>>> enough to be allowed to push it.
>> Where are these rules documented? I looked for them on
>> openjdk.java.net, but could not find them unfortunately.
> Hotspot rules are buried in here:
Thanks for the link, David.
For build code, we don't have any such set of rules, so the absence of
rules kind of is the rules. The rule about at least one reviewer is
enforced by the JDK project (and jcheck), but that's about it.
Hopefully, with Project Skara, many rules such as these can be enforced
and/or informed about automatically with bots.
> "Before pushing"
> You must be a Committer in the JDK project
> You need a non-JEP JBS issue for tracking
> Your change must have been available for review at least 24 hours
> to accommodate for all time zones
> 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 run all relevant testing to make sure your actual change
> is working
> 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.
More information about the core-libs-dev