Nominating Mikael Gerdin to be an OpenJDK committer and a reviewer

mark.reinhold at oracle.com mark.reinhold at oracle.com
Tue Jun 28 05:05:05 UTC 2011


2011/6/27 0:42 -0700, bengt.rutisson at oracle.com:
> With the new OpenJDK bylaws almost in place we need to follow the process that
> they outline to get OpenJDK user names even for the people working at
> Oracle. Mikael Gerdin does not have an OpenJDK user name yet. He helped me a
> lot with the CMS bug that I have been working on during the spring and he also
> reviewed and had good comments on my quicksort implementation. I would very
> much like to list him as a reviewer when I push this change.
> 
> To grant Mikael reviewer status in OpenJDK we need to first make him a
> committer (lazy consensus  - no vetoes) and then vote him in as a reviewer (at
> least three votes in favor and no vetoes).
> 
> Since this is blocking my push, could I please have some votes for making
> Mikael Gerdin a committer and a reviewer?
> 
> Relevant part of the bylaws:
> http://openjdk.java.net/groups/gb/bylaws/draft-openjdk-bylaws-10#_7
> 
> Copying Mark on this thread since this is the first time this is done and I
> would like to know that we are on the right track.

I appreciate the effort you're taking to try to follow the proposed
Bylaws, but I'm afraid it's a bit premature.  Even assuming that they're
ratified tomorrow -- which looks likely -- it will take a bit of time to
execute the transition outlined in Appendix B [1].  Until we've finished
that we can't really even identify the proper set of Committers to vote
upon any particular nomination of a new Committer.

Aside from that, while I'm sure that Mikael is a very capable engineer he
has no history of past code contributions in OpenJDK and thus there isn't
a basis upon which existing Committers could judge his prior work when
evaluating his nomination.

Finally, the Reviewer role is meant to align with the definition in the
OpenJDK Developers' Guide [2]:

    Reviewers should be aware that they take full responsibility for
    the appropriateness and correctness of any changes in their area
    of expertise.  If something goes wrong (e.g., the build breaks)
    and the change's author is unavailable, they may be asked to deal
    with the problem.

A Reviewer, in other words, needs to be an experienced Committer who is
ready, willing, and able to deal with any failure arising from the change
under review, including but not limited to dealing with a broken build,
repairing merge errors, producing follow-on fixes, and so forth.

I've heard from others that Mikael provided valuable assistance to you in
producing this fix, and I have no reason to doubt that.  He should by all
means be given due credit for his work, but trying to vote him into the
Committer and Reviewer roles is not the right approach.

Unfortunately we do not, at the moment, have a great alternative in place
and ready to go.  If you're anxious to push your changeset very soon then
I suggest acknowledging Mikael in the "Summary" line of your changeset
comment, something like this:

    Summary: Also reviewed by mikael.gerdin at oracle.com

A better solution might be to modify the jcheck extension to accept new
lines of the form:

    Also-reviewed-by: mikael.gerdin at oracle.com

This is different from the existing "Reviewed-by" line in that it accepts
an e-mail address rather than an OpenJDK username, and it doesn't carry
the implication that the named individual has the formal Reviewer role.

If you can wait a few days we can probably extend jcheck to do this, but
we'd have to discuss such a proposal more widely a bit first.

Thanks again for trying to follow the proposed Bylaws here, and sorry for
all the confusion.  I hope this guidance helps.  We're already planning
to write up a "how-to" document to help people understand and operate the
processes defined in the Bylaws; hopefully that will make things more
efficient for everyone once it's available.

- Mark


[1] http://openjdk.java.net/groups/gb/bylaws/draft-openjdk-bylaws-10#_B
[2] http://openjdk.java.net/guide/changePlanning.html



More information about the hotspot-gc-dev mailing list