RFR: (T) 8241144 Javadoc is not generated for new module jdk.nio.mapmode
Could I please have a review for this trivial fix to the module make file which ensures that javadoc is generated for new module jdk.nio.mapmode created as part of the implementation of JEP 352. The original patch added the module to the BOOT_MODULES list but was not to the DOCS_MODULES list. JIRA: https://bugs.openjdk.java.net/browse/JDK-8241144 webrev: http://cr.openjdk.java.net/~adinn/8241144/webrev Testing: Built image and compiled + ran Hello World. Built make target docs-jdk-api-javadoc and checked module jdk.nio.mapmode was included in output regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill
Looks good. /Erik On 2020-03-23 10:56, Andrew Dinn wrote:
Could I please have a review for this trivial fix to the module make file which ensures that javadoc is generated for new module jdk.nio.mapmode created as part of the implementation of JEP 352. The original patch added the module to the BOOT_MODULES list but was not to the DOCS_MODULES list.
JIRA: https://bugs.openjdk.java.net/browse/JDK-8241144 webrev: http://cr.openjdk.java.net/~adinn/8241144/webrev
Testing:
Built image and compiled + ran Hello World.
Built make target docs-jdk-api-javadoc and checked module jdk.nio.mapmode was included in output
regards,
Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill
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 update a side, it really is a 1-liner :-). I will push to the dev tree and request a backport to jdk14u. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill
On 2020-03-23 10:56, Andrew Dinn wrote:
Could I please have a review for this trivial fix to the module make file which ensures that javadoc is generated for new module jdk.nio.mapmode created as part of the implementation of JEP 352. The original patch added the module to the BOOT_MODULES list but was not to the DOCS_MODULES list.
JIRA: https://bugs.openjdk.java.net/browse/JDK-8241144 webrev: http://cr.openjdk.java.net/~adinn/8241144/webrev
Testing:
Built image and compiled + ran Hello World.
Built make target docs-jdk-api-javadoc and checked module jdk.nio.mapmode was included in output
regards,
Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill
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 update 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. (And for the record, you can add me as reviewer as well, if you wish :)) /Magnus
I will push to the dev tree and request a backport to jdk14u.
regards,
Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill
On 2020-03-23 10:56, Andrew Dinn wrote:
Could I please have a review for this trivial fix to the module make file which ensures that javadoc is generated for new module jdk.nio.mapmode created as part of the implementation of JEP 352. The original patch added the module to the BOOT_MODULES list but was not to the DOCS_MODULES list.
JIRA: https://bugs.openjdk.java.net/browse/JDK-8241144 webrev: http://cr.openjdk.java.net/~adinn/8241144/webrev
Testing:
Built image and compiled + ran Hello World.
Built make target docs-jdk-api-javadoc and checked module jdk.nio.mapmode was included in output
regards,
Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill
On 24/03/2020 09:10, Magnus Ihse Bursie wrote:
On 2020-03-24 09:59, Andrew Dinn wrote:
I'm assuming that also implies it is trivial (because, copyright update 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.
Ah ok, thanks for the advice. I'll push as soon as hg.openjdk.java.net comes back to life.
(And for the record, you can add me as reviewer as well, if you wish :)) You are on the list :-)
regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill
* 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 update 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.
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 update 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: https://wiki.openjdk.java.net/display/HotSpot/HotSpot+How+To "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. ---- Cheers, David
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 update 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:
https://wiki.openjdk.java.net/display/HotSpot/HotSpot+How+To 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. /Magnus
"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. ----
Cheers, David
participants (5)
-
Andrew Dinn
-
David Holmes
-
Erik Joelsson
-
Florian Weimer
-
Magnus Ihse Bursie