Re: Review request: 8194871: Fix mistakes in FX API docs

[Kevin Rushforth]

Uploaded here:

http://cr.openjdk.java.net/~kcr/8194871/webrev.01/

This looks good.

+1

I'll push it tomorrow.

-- Kevin


Nir Lisker wrote:

Attached a new webrev.

On Thu, Jan 11, 2018 at 2:27 AM, Kevin Rushforth 
> wrote:


Since we are talking about the layout bounds of a node, I would
avoid using the term '3D scene' (or subscene) since in this case
it is the node that has the characteristic of 3D (geometry or
transforms) associated with it.

Anyway, let's go with the note at the end somewhere. Since layout
is a 2D concept, I think it's fine if 3D users don't see anything
about 3D until later.

Do you want to send a delta patch for that? Or you can send an
entire updated webrev. Whichever you prefer.


-- Kevin


Nir Lisker wrote:

Yes, I initially had it as a note in the end saying something
like this:

 Note that for nodes in a 3D Scene (or SubScene),
layoutBounds is cuboid. 


but thought that for someone working with 3D, seeing a 2D
discussion all the way until the end will be confusing. (Also
thought about putting a footnote at the end of the first
sentence, but that's not a recommended style as far as I know.)
My only slight concern is that "3D shapes" might hint at the
Shape3D class, while any node in a 3D environment will have 3D
bounds. This is also a technicality, so I wouldn't mind either
way. Feel free to make a final verdict.

On Thu, Jan 11, 2018 at 1:17 AM, Kevin Rushforth
>
wrote:

The changes look good to me for the most part. I only have
one comment.

Node.java:

- * The rectangular bounds that should be used for layout ...
+ * The rectangular (cuboid for 3D nodes) bounds that
should be used for layout ...

While technically correct, in that the layout bounds of a
TriangleMesh or Sphere will be a 3D bounds, layout is a 2D
operation, so this seems a bit misleading. If you still feel
that a comment is desired, then I would recommend it not
being in the opening sentence, but rather a note later in the
description...something like:

Note that for 3D shapes, the layout bounds is actually a
rectangular box with X, Y, and Z values, although only X and
Y are used in layout calculations.


-- Kevin


Kevin Rushforth wrote:

I just removed the trailing whitespace (using the handy
tools/scripts/checkWhiteSpace script with the '-F' option).

-- Kevin


Nir Lisker wrote:

Thanks,
 



modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209:
Trailing whitespace


That one is an empty line inside a code block, if it matters.

On Thu, Jan 11, 2018 at 12:14 AM, Kevin Rushforth
> wrote:

> I'll review it, and sponsor the change. Since I will
be pushing it, I will need one more reviewer.

Actually, this is incorrect. As long as I list you as
contributor, jcheck is perfectly happy with just me as
reviewer.

If anyone else wants to review it, too, that would be
fine, but not necessary for this type of fix.

-- Kevin



Kevin Rushforth wrote:

Thank you for providing the patch. I uploaded it to
cr.openjdk.java.net  for
easy browsing:

http://cr.openjdk.java.net/~kcr/8194871/webrev.00/


I'll review it, and sponsor the change. Since I will
be pushing it, I will need one more reviewer.

My quick sanity checking shows trailing whitespace in
two files, which would cause jcheck to fail:

$ hg jcheck

modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209:
Trailing whitespace

modules/javafx.graphics/src/main/java/javafx/animation/Transition.java:161:
Trailing whitespace

I can fix this before I push.

-- Kevin


Nir Lisker wrote:

Hi Kevin,

Please review the attached webrev.

I addressed a few fixes I found as I was working, so
they are not listed in the JIRA report.

About Transition#getParentTargetNode:
The current behavior of parent-child relationship is
that an animation can be added to multiple parent
transitions. Each parent transition will see that
animation as its child, however, the child will see
only one of 

Re: Review request: 8194871: Fix mistakes in FX API docs

[Kevin Rushforth]

Since we are talking about the layout bounds of a node, I would avoid 
using the term '3D scene' (or subscene) since in this case it is the 
node that has the characteristic of 3D (geometry or transforms) 
associated with it.


Anyway, let's go with the note at the end somewhere. Since layout is a 
2D concept, I think it's fine if 3D users don't see anything about 3D 
until later.


Do you want to send a delta patch for that? Or you can send an entire 
updated webrev. Whichever you prefer.


-- Kevin


Nir Lisker wrote:

Yes, I initially had it as a note in the end saying something like this:

 Note that for nodes in a 3D Scene (or SubScene), layoutBounds is 
cuboid. 

but thought that for someone working with 3D, seeing a 2D discussion 
all the way until the end will be confusing. (Also thought about 
putting a footnote at the end of the first sentence, but that's not a 
recommended style as far as I know.)
My only slight concern is that "3D shapes" might hint at the Shape3D 
class, while any node in a 3D environment will have 3D bounds. This is 
also a technicality, so I wouldn't mind either way. Feel free to make 
a final verdict.


On Thu, Jan 11, 2018 at 1:17 AM, Kevin Rushforth 
> wrote:


The changes look good to me for the most part. I only have one
comment.

Node.java:

- * The rectangular bounds that should be used for layout ...
+ * The rectangular (cuboid for 3D nodes) bounds that should
be used for layout ...

While technically correct, in that the layout bounds of a
TriangleMesh or Sphere will be a 3D bounds, layout is a 2D
operation, so this seems a bit misleading. If you still feel that
a comment is desired, then I would recommend it not being in the
opening sentence, but rather a note later in the
description...something like:

Note that for 3D shapes, the layout bounds is actually a
rectangular box with X, Y, and Z values, although only X and Y are
used in layout calculations.


-- Kevin


Kevin Rushforth wrote:

I just removed the trailing whitespace (using the handy
tools/scripts/checkWhiteSpace script with the '-F' option).

-- Kevin


Nir Lisker wrote:

Thanks,
 



modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209:
Trailing whitespace


That one is an empty line inside a code block, if it matters.

On Thu, Jan 11, 2018 at 12:14 AM, Kevin Rushforth
>
wrote:

> I'll review it, and sponsor the change. Since I will be
pushing it, I will need one more reviewer.

Actually, this is incorrect. As long as I list you as
contributor, jcheck is perfectly happy with just me as reviewer.

If anyone else wants to review it, too, that would be fine,
but not necessary for this type of fix.

-- Kevin



Kevin Rushforth wrote:

Thank you for providing the patch. I uploaded it to
cr.openjdk.java.net  for easy
browsing:

http://cr.openjdk.java.net/~kcr/8194871/webrev.00/


I'll review it, and sponsor the change. Since I will be
pushing it, I will need one more reviewer.

My quick sanity checking shows trailing whitespace in two
files, which would cause jcheck to fail:

$ hg jcheck

modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209:
Trailing whitespace

modules/javafx.graphics/src/main/java/javafx/animation/Transition.java:161:
Trailing whitespace

I can fix this before I push.

-- Kevin


Nir Lisker wrote:

Hi Kevin,

Please review the attached webrev.

I addressed a few fixes I found as I was working, so they
are not listed in the JIRA report.

About Transition#getParentTargetNode:
The current behavior of parent-child relationship is that
an animation can be added to multiple parent transitions.
Each parent transition will see that animation as its
child, however, the child will see only one of those
animations as its parent - the one to which is was added
last. This asymmetry is a recipe for trouble (and I argue
should be addressed at some point).
For this reason, the doc does not specify the "last one
wins" behavior, so that no contract is created. This means
that it's not clear which parent is going to be queried on
each (recursive) invocation.

Most of the changes could be backported to 8 and 9. In 9,
the methods getRangeShape and getUnderlineShape of
TextAreaSkin are also missing documentation.

Re: Review request: 8194871: Fix mistakes in FX API docs

[Nir Lisker]

Yes, I initially had it as a note in the end saying something like this:

 Note that for nodes in a 3D Scene (or SubScene), layoutBounds is
cuboid.

but thought that for someone working with 3D, seeing a 2D discussion all
the way until the end will be confusing. (Also thought about putting a
footnote at the end of the first sentence, but that's not a recommended
style as far as I know.)
My only slight concern is that "3D shapes" might hint at the Shape3D class,
while any node in a 3D environment will have 3D bounds. This is also a
technicality, so I wouldn't mind either way. Feel free to make a final
verdict.

On Thu, Jan 11, 2018 at 1:17 AM, Kevin Rushforth  wrote:

> The changes look good to me for the most part. I only have one comment.
>
> Node.java:
>
> - * The rectangular bounds that should be used for layout ...
> + * The rectangular (cuboid for 3D nodes) bounds that should be used
> for layout ...
>
> While technically correct, in that the layout bounds of a TriangleMesh or
> Sphere will be a 3D bounds, layout is a 2D operation, so this seems a bit
> misleading. If you still feel that a comment is desired, then I would
> recommend it not being in the opening sentence, but rather a note later in
> the description...something like:
>
> Note that for 3D shapes, the layout bounds is actually a rectangular
> box with X, Y, and Z values, although only X and Y are used in layout
> calculations.
>
>
> -- Kevin
>
>
> Kevin Rushforth wrote:
>
> I just removed the trailing whitespace (using the handy
> tools/scripts/checkWhiteSpace script with the '-F' option).
>
> -- Kevin
>
>
> Nir Lisker wrote:
>
> Thanks,
>
>
>> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209:
>> Trailing whitespace
>
>
> That one is an empty line inside a code block, if it matters.
>
> On Thu, Jan 11, 2018 at 12:14 AM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> > I'll review it, and sponsor the change. Since I will be pushing it, I
>> will need one more reviewer.
>>
>> Actually, this is incorrect. As long as I list you as contributor, jcheck
>> is perfectly happy with just me as reviewer.
>>
>> If anyone else wants to review it, too, that would be fine, but not
>> necessary for this type of fix.
>>
>> -- Kevin
>>
>>
>>
>> Kevin Rushforth wrote:
>>
>> Thank you for providing the patch. I uploaded it to cr.openjdk.java.net
>> for easy browsing:
>>
>> http://cr.openjdk.java.net/~kcr/8194871/webrev.00/
>>
>> I'll review it, and sponsor the change. Since I will be pushing it, I
>> will need one more reviewer.
>>
>> My quick sanity checking shows trailing whitespace in two files, which
>> would cause jcheck to fail:
>>
>> $ hg jcheck
>> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209:
>> Trailing whitespace
>> modules/javafx.graphics/src/main/java/javafx/animation/Transition.java:161:
>> Trailing whitespace
>>
>> I can fix this before I push.
>>
>> -- Kevin
>>
>>
>> Nir Lisker wrote:
>>
>> Hi Kevin,
>>
>> Please review the attached webrev.
>>
>> I addressed a few fixes I found as I was working, so they are not listed
>> in the JIRA report.
>>
>> About Transition#getParentTargetNode:
>> The current behavior of parent-child relationship is that an animation
>> can be added to multiple parent transitions. Each parent transition will
>> see that animation as its child, however, the child will see only one of
>> those animations as its parent - the one to which is was added last. This
>> asymmetry is a recipe for trouble (and I argue should be addressed at some
>> point).
>> For this reason, the doc does not specify the "last one wins" behavior,
>> so that no contract is created. This means that it's not clear which parent
>> is going to be queried on each (recursive) invocation.
>>
>> Most of the changes could be backported to 8 and 9. In 9, the methods
>> getRangeShape and getUnderlineShape of TextAreaSkin are also missing
>> documentation.
>>
>>
>

Re: Review request: 8194871: Fix mistakes in FX API docs

[Kevin Rushforth]

The changes look good to me for the most part. I only have one comment.

Node.java:

- * The rectangular bounds that should be used for layout ...
+ * The rectangular (cuboid for 3D nodes) bounds that should be used 
for layout ...


While technically correct, in that the layout bounds of a TriangleMesh 
or Sphere will be a 3D bounds, layout is a 2D operation, so this seems a 
bit misleading. If you still feel that a comment is desired, then I 
would recommend it not being in the opening sentence, but rather a note 
later in the description...something like:


   Note that for 3D shapes, the layout bounds is actually a rectangular 
box with X, Y, and Z values, although only X and Y are used in layout 
calculations.


-- Kevin


Kevin Rushforth wrote:
I just removed the trailing whitespace (using the handy 
tools/scripts/checkWhiteSpace script with the '-F' option).


-- Kevin


Nir Lisker wrote:

Thanks,
 



modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209:
Trailing whitespace


That one is an empty line inside a code block, if it matters.

On Thu, Jan 11, 2018 at 12:14 AM, Kevin Rushforth 
> wrote:


> I'll review it, and sponsor the change. Since I will be pushing
it, I will need one more reviewer.

Actually, this is incorrect. As long as I list you as
contributor, jcheck is perfectly happy with just me as reviewer.

If anyone else wants to review it, too, that would be fine, but
not necessary for this type of fix.

-- Kevin



Kevin Rushforth wrote:

Thank you for providing the patch. I uploaded it to
cr.openjdk.java.net  for easy browsing:

http://cr.openjdk.java.net/~kcr/8194871/webrev.00/


I'll review it, and sponsor the change. Since I will be pushing
it, I will need one more reviewer.

My quick sanity checking shows trailing whitespace in two files,
which would cause jcheck to fail:

$ hg jcheck

modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209:
Trailing whitespace
modules/javafx.graphics/src/main/java/javafx/animation/Transition.java:161:
Trailing whitespace

I can fix this before I push.

-- Kevin


Nir Lisker wrote:

Hi Kevin,

Please review the attached webrev.

I addressed a few fixes I found as I was working, so they are
not listed in the JIRA report.

About Transition#getParentTargetNode:
The current behavior of parent-child relationship is that an
animation can be added to multiple parent transitions. Each
parent transition will see that animation as its child,
however, the child will see only one of those animations as its
parent - the one to which is was added last. This asymmetry is
a recipe for trouble (and I argue should be addressed at some
point).
For this reason, the doc does not specify the "last one wins"
behavior, so that no contract is created. This means that it's
not clear which parent is going to be queried on each
(recursive) invocation.

Most of the changes could be backported to 8 and 9. In 9, the
methods getRangeShape and getUnderlineShape of TextAreaSkin are
also missing documentation.

Re: Review request: 8194871: Fix mistakes in FX API docs

[Kevin Rushforth]

I just removed the trailing whitespace (using the handy 
tools/scripts/checkWhiteSpace script with the '-F' option).


-- Kevin


Nir Lisker wrote:

Thanks,
 



modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209:
Trailing whitespace


That one is an empty line inside a code block, if it matters.

On Thu, Jan 11, 2018 at 12:14 AM, Kevin Rushforth 
> wrote:


> I'll review it, and sponsor the change. Since I will be pushing
it, I will need one more reviewer.

Actually, this is incorrect. As long as I list you as contributor,
jcheck is perfectly happy with just me as reviewer.

If anyone else wants to review it, too, that would be fine, but
not necessary for this type of fix.

-- Kevin



Kevin Rushforth wrote:

Thank you for providing the patch. I uploaded it to
cr.openjdk.java.net  for easy browsing:

http://cr.openjdk.java.net/~kcr/8194871/webrev.00/


I'll review it, and sponsor the change. Since I will be pushing
it, I will need one more reviewer.

My quick sanity checking shows trailing whitespace in two files,
which would cause jcheck to fail:

$ hg jcheck

modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209:
Trailing whitespace
modules/javafx.graphics/src/main/java/javafx/animation/Transition.java:161:
Trailing whitespace

I can fix this before I push.

-- Kevin


Nir Lisker wrote:

Hi Kevin,

Please review the attached webrev.

I addressed a few fixes I found as I was working, so they are
not listed in the JIRA report.

About Transition#getParentTargetNode:
The current behavior of parent-child relationship is that an
animation can be added to multiple parent transitions. Each
parent transition will see that animation as its child, however,
the child will see only one of those animations as its parent -
the one to which is was added last. This asymmetry is a
recipe for trouble (and I argue should be addressed at some point).
For this reason, the doc does not specify the "last one wins"
behavior, so that no contract is created. This means that it's
not clear which parent is going to be queried on each
(recursive) invocation.

Most of the changes could be backported to 8 and 9. In 9, the
methods getRangeShape and getUnderlineShape of TextAreaSkin are
also missing documentation.

Re: Review request: 8194871: Fix mistakes in FX API docs

[Nir Lisker]

Thanks,


> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209:
> Trailing whitespace


That one is an empty line inside a code block, if it matters.

On Thu, Jan 11, 2018 at 12:14 AM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:

> > I'll review it, and sponsor the change. Since I will be pushing it, I
> will need one more reviewer.
>
> Actually, this is incorrect. As long as I list you as contributor, jcheck
> is perfectly happy with just me as reviewer.
>
> If anyone else wants to review it, too, that would be fine, but not
> necessary for this type of fix.
>
> -- Kevin
>
>
>
> Kevin Rushforth wrote:
>
> Thank you for providing the patch. I uploaded it to cr.openjdk.java.net
> for easy browsing:
>
> http://cr.openjdk.java.net/~kcr/8194871/webrev.00/
>
> I'll review it, and sponsor the change. Since I will be pushing it, I will
> need one more reviewer.
>
> My quick sanity checking shows trailing whitespace in two files, which
> would cause jcheck to fail:
>
> $ hg jcheck
> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209:
> Trailing whitespace
> modules/javafx.graphics/src/main/java/javafx/animation/Transition.java:161:
> Trailing whitespace
>
> I can fix this before I push.
>
> -- Kevin
>
>
> Nir Lisker wrote:
>
> Hi Kevin,
>
> Please review the attached webrev.
>
> I addressed a few fixes I found as I was working, so they are not listed
> in the JIRA report.
>
> About Transition#getParentTargetNode:
> The current behavior of parent-child relationship is that an animation can
> be added to multiple parent transitions. Each parent transition will see
> that animation as its child, however, the child will see only one of those
> animations as its parent - the one to which is was added last. This
> asymmetry is a recipe for trouble (and I argue should be addressed at some
> point).
> For this reason, the doc does not specify the "last one wins" behavior, so
> that no contract is created. This means that it's not clear which parent is
> going to be queried on each (recursive) invocation.
>
> Most of the changes could be backported to 8 and 9. In 9, the methods
> getRangeShape and getUnderlineShape of TextAreaSkin are also missing
> documentation.
>
>

Re: Review request: 8194871: Fix mistakes in FX API docs

[Kevin Rushforth]

> I'll review it, and sponsor the change. Since I will be pushing it, I 
will need one more reviewer.


Actually, this is incorrect. As long as I list you as contributor, 
jcheck is perfectly happy with just me as reviewer.


If anyone else wants to review it, too, that would be fine, but not 
necessary for this type of fix.


-- Kevin


Kevin Rushforth wrote:
Thank you for providing the patch. I uploaded it to 
cr.openjdk.java.net for easy browsing:


http://cr.openjdk.java.net/~kcr/8194871/webrev.00/

I'll review it, and sponsor the change. Since I will be pushing it, I 
will need one more reviewer.


My quick sanity checking shows trailing whitespace in two files, which 
would cause jcheck to fail:


$ hg jcheck
modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209: 
Trailing whitespace
modules/javafx.graphics/src/main/java/javafx/animation/Transition.java:161: 
Trailing whitespace


I can fix this before I push.

-- Kevin


Nir Lisker wrote:

Hi Kevin,

Please review the attached webrev.

I addressed a few fixes I found as I was working, so they are not 
listed in the JIRA report.


About Transition#getParentTargetNode:
The current behavior of parent-child relationship is that an 
animation can be added to multiple parent transitions. Each parent 
transition will see that animation as its child, however, the child 
will see only one of those animations as its parent - the one to 
which is was added last. This asymmetry is a recipe for trouble (and 
I argue should be addressed at some point).
For this reason, the doc does not specify the "last one wins" 
behavior, so that no contract is created. This means that it's not 
clear which parent is going to be queried on each (recursive) 
invocation.


Most of the changes could be backported to 8 and 9. In 9, the methods 
getRangeShape and getUnderlineShape of TextAreaSkin are also missing 
documentation.

Re: Review request: 8194871: Fix mistakes in FX API docs

[Kevin Rushforth]

Thank you for providing the patch. I uploaded it to cr.openjdk.java.net 
for easy browsing:


http://cr.openjdk.java.net/~kcr/8194871/webrev.00/

I'll review it, and sponsor the change. Since I will be pushing it, I 
will need one more reviewer.


My quick sanity checking shows trailing whitespace in two files, which 
would cause jcheck to fail:


$ hg jcheck
modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209: 
Trailing whitespace
modules/javafx.graphics/src/main/java/javafx/animation/Transition.java:161: 
Trailing whitespace


I can fix this before I push.

-- Kevin


Nir Lisker wrote:

Hi Kevin,

Please review the attached webrev.

I addressed a few fixes I found as I was working, so they are not 
listed in the JIRA report.


About Transition#getParentTargetNode:
The current behavior of parent-child relationship is that an animation 
can be added to multiple parent transitions. Each parent transition 
will see that animation as its child, however, the child will see only 
one of those animations as its parent - the one to which is was added 
last. This asymmetry is a recipe for trouble (and I argue should be 
addressed at some point).
For this reason, the doc does not specify the "last one wins" 
behavior, so that no contract is created. This means that it's not 
clear which parent is going to be queried on each (recursive) invocation.


Most of the changes could be backported to 8 and 9. In 9, the methods 
getRangeShape and getUnderlineShape of TextAreaSkin are also missing 
documentation.

Review request: 8194871: Fix mistakes in FX API docs

[Nir Lisker]

Hi Kevin,

Please review the attached webrev.

I addressed a few fixes I found as I was working, so they are not listed in
the JIRA report.

About Transition#getParentTargetNode:
The current behavior of parent-child relationship is that an animation can
be added to multiple parent transitions. Each parent transition will see
that animation as its child, however, the child will see only one of those
animations as its parent - the one to which is was added last. This
asymmetry is a recipe for trouble (and I argue should be addressed at some
point).
For this reason, the doc does not specify the "last one wins" behavior, so
that no contract is created. This means that it's not clear which parent is
going to be queried on each (recursive) invocation.

Most of the changes could be backported to 8 and 9. In 9, the methods
getRangeShape and getUnderlineShape of TextAreaSkin are also missing
documentation.

Result: New OpenJFX Committer: Laurent Bourgès

[Kevin Rushforth]

Voting for Laurent Bourgès [1] to OpenJFX Committer [2] is now closed.

Yes: 8
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
to approve the nomination.


-- Kevin

[1] http://openjdk.java.net/census#lbourges

[2] 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-December/021116.html

[11] Review request for 8193368: [OS X] Remove redundant files

[Murali Billa]

 

Hi,


Please review the below simple fix.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8193368

 

Webrev: http://cr.openjdk.java.net/~mbilla/8193368/webrev.00/

 


Thanks,

Murali

Re: Error while pushing changeset

[Kevin Rushforth]

The bug has now been moved to the JDK project, so the ID has changed to 
8194871.


https://bugs.openjdk.java.net/browse/JDK-8194871

I'll upload your webrev once you send it.

Thanks.

-- Kevin


Nir Lisker wrote:

Submitted a new bug with ID: 9052190.

On Tue, Jan 9, 2018 at 10:51 PM, Kevin Rushforth 
> wrote:




Nir Lisker wrote:


If there isn't an existing JBS issue, then please file one


I thought I would point to "8188314: Fix typos in FX API docs"
even though the exact changes I'm proposing are not listed there,
but I can submit a new bug just for those if it really matters
(it will be another Fix Typos issue).


We'll need a new JBS bug, since that one is already resolved with
a changeset (every changeset needs a unique bug ID). Feel free to
use the same synopsis if you like.


 


I also note that with simple javadoc changes, this can be
done prior to your OCA being recorded if you like


Yes, as a Participant. Iv'e signed the Sun CA some 7 years ago
and this week signed the OCA in case it didn't transfer over.
It's not crucial to handle it right now since the changes are
trivial.


Good.



I haven't gotten to your email from yesterday


It's a bit of a loaded one so it can wait after the RDP. I only
needed the minimum info to get these fixes before the RDP.


OK.

-- Kevin



- Nir

On Tue, Jan 9, 2018 at 9:43 PM, Kevin Rushforth
>
wrote:

> I also note that tith simple javadoc changes...

"with" simple ...

-- Kevin



Kevin Rushforth wrote:



Nir Lisker wrote:

> This shows a lack of understanding about our processes

Yes it does, which is why I asked about it yesterday.
I'll send a webrev.


Ah, I haven't gotten to your email from yesterday, since
I was on vacation and am still catching up. If you can
send a webrev, and a pointer to a JBS issue, I'll attach
it for you. If there isn't an existing JBS issue, then
please file one (and I'll see that it gets moved into the
JDK project quickly). I also note that tith simple
javadoc changes, this can be done prior to your OCA being
recorded if you like.

Thanks.

-- Kevin



Thanks,
Nir


On Tue, Jan 9, 2018 at 8:50 PM, Kevin Rushforth

>> wrote:

Why would you even try to push a changeset
without getting it
reviewed first???

This shows a lack of understanding about our
processes and
policies. Only committers have permission to push
changesets, and
only after review. Please familiarize yourself
with the policies
and procedures surrounding contributing to
OpenJFX [1] [2] [3] [4]
[5]. Once you are familiar with these policies
and have signed the
Oracle Contributor Agreement (OCA) you can work
with someone to
sponsor your change.

-- Kevin

[1] http://openjdk.java.net/contribute/

>
[2]
http://www.oracle.com/technetwork/community/oca-486395.html

   
>
[3]
   
https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report



   
>
[4]
https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews