HotSpot Style Guide change process

[Vladimir Kozlov]

Okay. I did not realize that we are already using "rough consensus" in our processes.
Thank you, Kim, for pointers. I take back my original suggestion.

My next suggestion is to change [rough consensus] link to https://tools.ietf.org/html/rfc7282 which is used by 
Vulnerability group and also referenced by Wikipedia. It is more formal and will be available for longer time.

Regards,
Vladimir

On 12/1/20 5:25 PM, David Holmes wrote:
> 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?
>>