On 3/25/2019 4:48 AM, Adam Farley8 wrote:
Hiya Joe,

Responses below.

Joe Darcy <joe.da...@oracle.com> wrote on 22/03/2019 17:06:38:

> From: Joe Darcy <joe.da...@oracle.com>
> To: Mandy Chung <mandy.ch...@oracle.com>, Adam Farley8
> <adam.far...@uk.ibm.com>
> Cc: core-libs-dev <core-libs-dev@openjdk.java.net>
> Date: 22/03/2019 17:07
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessException for final fields
> > On 3/22/2019 9:56 AM, Mandy Chung wrote:
> Hi Adam,

> On 3/22/19 8:40 AM, Joe Darcy wrote:
> > Please update distinct versions of a webrev (e.g. distinguished with
> .1, .2 directory names) rather than overwriting a single one. This
> make it easier for those coming to the review thread later to see
> the evolution of the changes over time.

> > +1
>
> I had requested new test in the webrev during my review. That really
> helps me, a reviewer, to keep track what has been changed easily.
> It will also give you an idea how many revisions this review
> involves when you started for a code review (as opposed to asking
> for "how to fix this issue").
>
> I was asked to read the regression test that is attached to JBS issue [1]
> I was asked to review a diff (cut-n-paste) on the mail when I
> requested a webrev to include a regression test. [2]
>
> On Jan 31, 2019 [3], I includeed a link to the OpenJDK developer
> guide and I was hoping you read the guideline and be familiar with
> it which should help you contributing to the OpenJDK.
>
> I was disappointed to get your conclusion:
> Historically, the bigger the change I propose, the more months it takes
> the OpenJDK community to approve.
> > OpenJDK is a community one participates in, not a service one sits
> in judgement over.
> -Joe

No judgement was implied in my original comment. I was attempting to
explain why I'd favoured a smaller code change over a large code change,
and you're telling me I was unclear.

Code changes can take a while to gain community approval, and it makes
sense to me that I would notice that and attempt to make my code
changes as small and simple as possible, to avoid delays, and make
things easier for everyone.


There is a difference between asking "What can I do to reduce the review time on on my patches?" and simply stating in what would reasonably be interpreted in an accusatory tone "it takes months for the OpenJDK community to review my patches."

Answers to that question include, but are not limited to, following long-established project conventions around, for example, writing new tests, running regression tests oneself, accepting and acting on feedback from senior reviewers, etc.

Assuming a multi-month latency for getting patches in is longer than average, there is a large space of possible explanations for that. One set of explanations includes deficiencies in the reviewers or review process. Another set of explanations includes deficiencies in the patch or its author, such as argumentativeness or other cause requiring excessive involvement of and corrective action from the reviewers to get the patch to conform to the conventions and quality standards of the project.

In this project at least, the burden of proof is on the person advocating to get the patch in; the burden of proof is not on the reviewers for why the patch should be kept out.

-Joe

Reply via email to