CFV: New OpenJDK Members Group Member: Alex Kashchenko

[Andrew Hughes]

On 29/05/2020 16:30, Dalibor Topic wrote:
> 
> 
> On 28.05.2020 10:10, Andrew Hughes wrote:
>> I've responded in full in reply to Simon's vote, but on the specific
>> point raised here, votes for Alex to be made a committer are also in
>> progress:
>>
>> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-May/003173.html
>>
>> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011806.html
> 
> Thank you for mentioning that, Andrew.
> 
> The JDK Updates vote appears a bit too premature, as well, considering
> that Alex has made two contributions to that Project, rather than the
> usual eight.
> 
> For someone being proposed to become an OpenJDK Member, the rough guide
> is for them to be a Reviewer on a Project, which in turn as a rough
> guide means at least 32 changes having been contributed to a Project
> prior to the call for vote to become a Reviewer.
> 
> I think it's understandable that many people might see that the
> difference between 2 (or 1, or 8) and 32 stretches a bit too far even
> under most benevolent interpretations of rough guide constraints for
> this vote to be held successfully.
> 
> So I would suggest withdrawing this vote at this time.

I've withdrawn the Member vote. I wasn't aware the bar was quite so high
for this, especially given that there are some Members without even
authorship status.

I don't think the Updates committer status is premature. Alex has
certainly submitted more than two patches. The problem with doing
backports, particularly for 11u+, is that they are often clean backports
and retain original authorship data.

For example, https://bugs.openjdk.java.net/browse/JDK-8236996 shows Alex
doing the backport work for 8u, 11u & 13u, but none of the resulting
changesets credit him. This is fairly normal for backporting work.

Depriving Alex of committer status only serves to create more work for
the rest of us, who then have to push his changesets on his behalf. It
also effectively makes doing clean backport work pointless for him, as
someone else then has to apply the fix, build and push it.

At the end of the day, these commit numbers are guidelines and the
arbitrator here is the voting process. I'm not aware of any formal
objections as yet to Alex's CFV, and in fact, there are already several
yes votes.

I can see the point in not allowing commit status if someone is deemed
untrustworthy, but complaining that they don't have enough commits when
they can't create commits seems a little unhelpful.

Moreover, it makes no sense for him to have commit status on 8u and not
later versions, when, had he achieved 8u commit status earlier, it would
have been automatically rolled over to the later versions.

> 
>> With regard to authorship status, I believe that's something that can
>> simply be bestowed on request to the project lead. I'm not sure why that
>> has not taken place earlier, but I don't believe it's a pre-requisite to
>> committer status either.
> 
> Author status is not required prior to becoming a Committer, but it's
> also worth pointing out that Project Leads do not just go around
> bestowing Author status on unwary Contributors without that actually
> being requested by the Contributor. That wouldn't make much sense.

I wasn't suggesting that. As I said, "bestowed on request [by the
contributor] to the project lead"

> 
> So for JDK Updates, I'd also additionally suggest withdrawing the
> Committer vote at this time, and having Alex simply request Author Role
> from its Project Lead, as a means of recording his current Role with
> that Project in the Census.
> 
> As the contributions continue to grow, so would the role with subsequent
> Committer etc. votes.

The author role doesn't really solve the problem of commits having to be
made on his behalf. He already has an OpenJDK ID by virtue of being
author on an earlier OpenJDK version.

Treating all these JDK versions as if they were completely different
projects doesn't really make much sense to me, and, as I said above,
that is backed up by the way roles are automatically applied when new
JDK versions appear.

> 
> cheers,
> dalibor topic

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222