CFV: New OpenJDK Committer: Martin Balao

jesper.wilhelmsson at jesper.wilhelmsson at
Thu Jun 28 18:53:00 UTC 2018

The last time this was up for debate I suggested to change the description on the OpenJDK page,, to something like:

"A Contributor who is trusted to use their push access in a responsible fashion and who has shown through previous work in the Project to understand the workflow and infrastructure required to work in the Project can be nominated."

I think we should try to make this happen.

> On 28 Jun 2018, at 20:23, Phil Race <philip.race at> wrote:
> 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 expect to
> stick around, and you should take into account the time period, technical difficulty and
> significance of their contributions rather than focusing on an absolute number.
> 8 is therefore a guideline based on some estimation of typical size + complexity of
> fixes in the project to show a sufficient body of work.
> -phil.
> On 06/28/2018 09:28 AM, Andrew Hughes wrote:
>> On 28 June 2018 at 07:42, Volker Simonis <volker.simonis at> 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 [1] 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,
>>> Volker
>>> [1]
>> 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 [0], 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
>> complexity.
>> 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 [1]. 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.
>> [0]
>> [1]
>> Thanks,

More information about the jdk-dev mailing list