[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-2d-dev
Subject: Re: IMPORTANT REMINDER: 2 Reviews (ie approvals) are required for most client-libs changes
From: Philip Race <philip.race () oracle ! com>
Date: 2023-07-31 15:50:45
Message-ID: 90fde90a-63e5-81f4-e82c-71a50e099dbf () oracle ! com
[Download RAW message or body]
Regarding : https://git.openjdk.org/jdk/pull/15064
please note the policy we have and have had for as long as OpenJDK has
been around.
And in this case there isn't even a client reviewer which makes two
problems !
-phil.
On 7/13/23 8:27 AM, Philip Race wrote:
> Please see "Code Reviews" on the Group page
> https://openjdk.org/groups/client-libs/ where it says
>
> The Java Client Library Group has always standardized on two approvals
> - where at least one must have the Reviewer role.
> Historically this was addressed entirely by social conventions but
> today the tooling plays a role - and the JDK project is set up to mark
> a PR as ready for integration after a single approval by a person with
> the Reviewer role - which is not consistent with the Client Libraries
> policy.
> The tooling cannot automatically enforce this on a per-module basis
> and it is not reasonable to expect others to add "/reviewers 2" to
> every PR.
> The fixer therefore needs to understand the policies and wait for a
> second approval.
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> As an example of a PR about which there was zero urgency and should
> have had a 2nd approval see
>
> https://github.com/openjdk/jdk/pull/14795
>
> -phil.
[Attachment #3 (text/html)]
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
Regarding : <a class="moz-txt-link-freetext" \
href="https://git.openjdk.org/jdk/pull/15064">https://git.openjdk.org/jdk/pull/15064</a><br>
please note the policy we have and have had for as long as OpenJDK
has been around.<br>
And in this case there isn't even a client reviewer which makes two
problems !<br>
<br>
-phil.<br>
<br>
<div class="moz-cite-prefix">On 7/13/23 8:27 AM, Philip Race wrote:<br>
</div>
<blockquote type="cite" \
cite="mid:be11e2a5-e66f-f1cd-6c0b-e1cefef003ea@oracle.com">
Please see "Code Reviews" on the Group page <br>
<a class="moz-txt-link-freetext" href="https://openjdk.org/groups/client-libs/" \
moz-do-not-send="true">https://openjdk.org/groups/client-libs/</a> where it says<br>
<br>
<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);
font-family: "DejaVu Sans", "Bitstream Vera
Sans", "Luxi Sans", Verdana, Arial, Helvetica;
font-size: 13.333333px; font-style: normal; font-variant-caps:
normal; font-weight: 400; letter-spacing: normal; orphans: auto;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px; text-decoration: none; display:
inline !important; float: none;">The Java Client Library Group
has always standardized on two approvals - where at least one
must have the Reviewer role.<br>
Historically this was addressed entirely by social conventions
but today the tooling plays a role - and the JDK project is set
up to mark a PR as ready for integration after a single approval
by a person with the Reviewer role - which is not consistent
with the Client Libraries policy.<br>
The tooling cannot automatically enforce this on a per-module
basis and it is not reasonable to expect others to add
"/reviewers 2" to every PR.<br>
The fixer therefore needs to understand the policies and wait
for a second approval.<br>
<br>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
<br>
As an example of a PR about which there was zero urgency and
should have had a 2nd approval see<br>
<br>
</span><a class="moz-txt-link-freetext" \
href="https://github.com/openjdk/jdk/pull/14795" \
moz-do-not-send="true">https://github.com/openjdk/jdk/pull/14795</a><br> <br>
-phil.<br>
</blockquote>
<br>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic