CFV: New JDK Updates Committer: Jie Kang

[David Holmes]

Hi Mario,

On 7/06/2020 4:28 am, Mario Torre wrote:
> On Sat, Jun 6, 2020 at 2:33 PM David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Mario,
> 
> Hi David,
> 
>> Please clarify which of these are actual contributions by Jie and which
>> are simply "hg import" of the original changeset. I do not consider a
>> clean import as a contribution. If there is more to this that warrants
>> being considered a contribution then please elaborate.
> 
> Here's more information about each backport:
> 
> Those required re-work:
> https://bugs.openjdk.java.net/browse/JDK-8205516
> https://bugs.openjdk.java.net/browse/JDK-8213448
> https://bugs.openjdk.java.net/browse/JDK-8232806
> 
> Those were "clean" backports (for some definition of clean):
> https://bugs.openjdk.java.net/browse/JDK-8214896
> https://bugs.openjdk.java.net/browse/JDK-8214925
> https://bugs.openjdk.java.net/browse/JDK-8218935
> https://bugs.openjdk.java.net/browse/JDK-8225694
> https://bugs.openjdk.java.net/browse/JDK-8223697
> https://bugs.openjdk.java.net/browse/JDK-8215771
> https://bugs.openjdk.java.net/browse/JDK-8233075
> https://bugs.openjdk.java.net/browse/JDK-8219904
> 
> However I have a real problem marking clean backports as a "simple hg
> import of the original changeset", because it's never the case. Each
> patch needs to be studied and understood and tested, even when it
> applied cleanly, so there's real work involved, and you can see this
> for example in the discussion about JDK-8223697, which despite
> applying cleanly was actually a result of a few back and forth and
> required assessment of another patch that didn't apply cleanly. I
> would be very worried if any developer would apply a patch, see that
> it's clean and just pushes it.

That can certainly be the case, but in other cases e.g.

https://bugs.openjdk.java.net/browse/JDK-8233075
https://bugs.openjdk.java.net/browse/JDK-8214896

the change is quite trivial (both the original change and the backport).

My point being that the onus is on the person posting the CFV to make 
sure that the contributions of the nominee can be clearly seen. In the 
case of jdk-updates and backports it is exceedingly difficult for voters 
to be able to know whether a backport was trivial or indeed reflects a 
significant contribution from someone else. As you note the process 
itself is flawed because the involvement of someone in a backport is not 
even be visible in the changeset. :(

> There's maybe an issue in the process where the updates project is
> also responsible to produce the topmost stable release (i.e. JDK15u)
> and so the Committer role is akin to that of Committer for the jdk-dev
> in this case, but for the most part the updates produce maintenance
> releases of typically older trains, like JDK 11 or 13 (8u is not in
> this by chance, because back then we had a separate update project for
> each version).
> 
> Selecting a Committer for those versions would be very difficult if we
> only allowed non clean backports as contributions, because the reality
> is that most of the backports apply cleanly or with trivial
> modifications, so the rationale behind a Yes vote, in my opinion,
> should be the quality of the work this developer does (which means
> also ensuring that a patch that is a clean backport is also
> contextually accurate and does not have unwanted side effects), the
> frequency of his contributions and the likelihood that he will
> continue contributing. Of course, YMMV, and I respect that.
> 
>> Further there is a hole in our role checking if a non-committer actually
>> pushed backport changesets in the first place!
> 
> Jie didn't push those patches, he contributed them and someone
> (usually Christopher!) pushed them.

Thanks for clarifying that.

Cheers,
David
-----

> Cheers,
> Mario
>