CFV: New OpenJDK Committer: Martin Balao
philip.race at oracle.com
Thu Jun 28 18:23:47 UTC 2018
It might be time to update the process document to say something about this
to avoid these debates.
I (personal view) think the intent of a number like 8 is to ensure that
a committer is,
well, .. committed ... as well as capable.
They've been around for a while, made contributions in that time and
stick around, and you should take into account the time period,
technical difficulty and
significance of their contributions rather than focusing on an absolute
8 is therefore a guideline based on some estimation of typical size +
fixes in the project to show a sufficient body of work.
On 06/28/2018 09:28 AM, Andrew Hughes wrote:
> On 28 June 2018 at 07:42, Volker Simonis <volker.simonis at gmail.com> wrote:
>> Hi Andrew,
>> I totally agree that we need more OpenJDK developers in the security
>> area and I'm sure Martin is a perfect fit for this role.
>> But the process document  clearly states that a "Contributor should
>> make at least eight significant contributions to that Project before
>> being nominated". From the references you've provided I can only see
>> five changes contributed by Martin. I'd therefore like to kindly ask
>> you to withdraw this CFV and postpone it until Martin has reached at
>> least the required minimum number of contributions.
>> Sorry for nit-picking, but I think we should all play by the same rules.
>> Best regards,
>>  http://openjdk.java.net/projects/#project-committer
> Hi Volker,
> Thanks for bringing this up. I don't think it's nit-picking; we should all
> try and be on the same page when it comes to such things.
> I wasn't aware of the document you refer to. My only reference
> when writing the original e-mail, and others in the past, has been
> the bylaws , which have no such prescription. I tend to concur
> with what Mario and Andrew Dinn have already said so well, in that
> this is intended as guidance, rather than a strict rule.
> It is hard to interpret it as such without also defining "significant" in
> some absolute way. Generally, what is regard a significant patch
> by one person may not be by another. I can also easily see how
> someone could easily produce more than eight patches of low
> complexity in the time it may take them to produce one of a higher
> Moreover, I do not see the need for such strong barriers on making
> someone a committer. If we were considering the post of reviewer,
> I may be more stringent, but all we are offering is the ability to push
> approved patches to the repositories. Unless we believe Martin
> to be a rogue agent, I don't see a value in this. We are not suggesting
> that he should be able to freely push patches without approval.
> All delaying his approval as committer achieves is creating more
> tedious work for others, as they then have to repeat his work of applying
> and building the patch before pushing it on his behalf. I do think we
> need to keep practicality and accessibility in mind, as well as strict
> conformance to the rules.
> What prompted me to post this yesterday is I also opened a similar
> vote for Severin on 8u . There, we have the even more bizarre situation
> that someone who can push to OpenJDK 9 and later can not push to
> OpenJDK 8, because, while such permissions are automatically carried
> to new versions of the JDK project, they are not applied retrospectively
> to older versions. This brought Martin to mind, and, to be fair to him, for
> his part, he rather modestly thought it was too soon to be proposed.
> Being aware of the work he has done, and is in the process of doing,
> I thought otherwise.
> It may well be that, by the time the two week voting period has expired,
> eight patches have been committed. My experience is that this has more
> to do with the availability of reviewers in the security space than anything
> else. If however, you still disagree and wish to veto, I bear you no hard
> feelings on the matter.
>  http://openjdk.java.net/bylaws#committer
>  http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-June/007588.html
More information about the jdk-dev