HotSpot Style Guide change process

[David Holmes]

Hi Kim,

"rough consensus" has good precedents and is something we should follow 
here IMO. OpenJDK by-laws are for the formal parts of the OpenJDK 
processes themselves, not for everything single thing done under the 
OpenJDK banner.

Cheers,
David

On 1/12/2020 4:43 pm, Kim Barrett wrote:
> When the Style Guide was updated for C++11/14 usage and other cleanup
> (JDK-8247976), a change process was added to it.  It says
> 
>    Proposed changes should be discussed on the
>    [HotSpot Developers](mailto:hotspot-dev at openjdk.java.net) mailing
>    list, and approved by
>    [rough consensus](https://en.wikipedia.org/wiki/Rough_consensus) of
>    the [HotSpot Group](https://openjdk.java.net/census#hotspot) Members.
>    The Group Lead determines whether consensus has been reached.
>    Changes are likely to be cautious and incremental, since HotSpot
>    coders have been using these guidelines for years.
> 
> Vladimir Kozlov has questioned this process and suggests another:
> 
>> I looked again on voting description for Style Guide changes. And it
>> references to `rough consensus` which is not in OpenJDK bylaws :
>> https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.html#L69
>>
>> I think it is bug (separate from these changes) and should be fixed by
>> using our rule http://openjdk.java.net/bylaws#three-vote-consensus
>> With Project Lead final vote we will need at least 2 other members votes
>> during 2 weeks review period. I think it is similar to `rough consensus`.
> 
> Use of "rough consensus" with an arbiter has precedent within the OpenJDK,
> though it's not used in the bylaws. The current text quoted above was based
> on
> 
> https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
> JEP 2.0, draft 2 - see "Planning", 4th bullet
> 
> and
> 
> https://openjdk.java.net/groups/vulnerability/
> OpenJDK Vulnerability Group - see "Making decisions"
> 
> So both the JEP Process and the Vulnerability Group use rough consensus,
> with the relevant lead as the arbiter.  (The V-Team page links to an IETF
> document describing rough consensus.  The HotSpot Style Guide links to
> the same Wikipedia article as the JEP 2.0 Process; that Wikipedia article
> references the IETF page.)
> 
> I called out the new change process specifically in the initial RFR email
> for JDK-8247976, but that part didn't generate much (any?) discussion.
> 
> If we don't like it we are certainly free to change.  And if Vladimir
> doesn't like it then we should change, since as HotSpot Lead he's fairly
> central to that process. But I don't think there's a "lack of precedent"
> or "not appropriate for OpenJDK" argument for changing.
> 
> I chose that process because I didn't want it to be too easy to make changes
> to the Style Guide. In particular, I think it should require more effort
> than is involved in a typical RFR.
> 
> Even if we don't change, and especially if we do, some further refinement of
> the mechanics may be needed. I think the current mechanics may have a
> problem that the request shows up in one's mailbox looking pretty much like
> an ordinary RFR. When I was originally thinking about that text we were in a
> world of pure email change requests, and the document was still a wiki page.
> With the move of the document to the jdk repository and the move to github
> and PRs + Skara support for changes, the mechanics are different. It might
> be better if it could be subject tagged differently, as we do with Call for
> Vote emails. There are probably things we could do about that, if others
> agree that's a problem. Or maybe some of you see other problems?
>