CFV: New hsx Committer: Eric McCorkle

[John Rose]

Vote: yes!

Changes are of the required raw bulk, *worse* than typical internal cancellation (code churn), and much better than average system-facing complexity.

I would consider vetoing a similar committer proposal that was (a) minimally sized and (b) had a significant degree of internal cancellation (code churn) and (c) had no other claim to significance.  Point (c) is *not* the case here.

Detailed comments:

The changesets presented, in physical size, are average representatives of what is already in the repository.  The size of "hg diff -c $rev" can be expected (as a rule of thumb) to be about 300 lines, or about 10k-12k bytes.  Eric's 8 changes match this almost exactly.  (I just rechecked those numbers on 100 recent non-merge changesets in hotspot-main, dates 9/18 - 10/18, with and without outer quartiles.)

There is a potential significance problem in Eric's changes, however, because they represent a certain amount of "code churn":  Some of the change sets cancel out previous changes in the same group of 8.  This is decisively counteracted by the fact that Eric's changes are very deep, with linkage to JDK changes and classfile spec. changes, and by other supporting comments Karen made in her call for votes.  In this case some (not all) of the churn was driven by external changes (the size of the flags field in the new attribute).

I point this out because, based on my reading of the bylaws, I expect a candidate committer's "portfolio" of eight or more changes to be at least of average significance relative to the existing repository.  For me, that starts with an expected bulk on the order of 8 changes averaging 300 LOC and 10kb.  The bulk can be reduced by significant internal cancellations (code churn).  The result will always be adjusted by ad hoc measures of significance, such as difficulty or architectural interconnectedness of changes.