Proposal to revise forest graph and integration practices for JDK 9

[Joe Darcy]

On 11/24/2013 5:24 PM, David Holmes wrote:
> On 25/11/2013 11:15 AM, Joe Darcy wrote:
>> On 11/24/2013 4:17 AM, Alan Bateman wrote:
>>> Probably a separate discussion but one thing that is not clear to many
>>> of us is the relationship between the hsx and jdk8 projects (some
>>> people have different roles in one vs. the other). Are hsx roles
>>> applicable in the JDK 9 project and the proposed structure? I'm just
>>> thinking of someone pushing to hotspot + jdk at the same time and
>>> whether they need to wear more than one shirt.
>>>
>>
>> That is a relevant point to raise. I think it would be a fine
>> simplification if those who have a certain status in the hsx project
>> were initialized to have the same status in the jdk9 project, similar to
>> what is done for the jdk8 -> jdk9 transition.
>
> I don't agree. I think this undermines the whole premise of the 
> qualifications for being an Author/Committer/Reviewer. Just because 
> you have those qualifications for hotspot does not mean you have them 
> for library changes - and vice versa. Maybe it is okay for Committers 
> (Author is a redundant role that should be deprecated) but not for 
> Reviewers.
>
> We should also clarify the approval process for pushing to the 
> different branches of this new forest ie number of Reviewers and where 
> they "reside".

The technical needs of reviewing are not always well-aligned with formal 
reviewer rolls. Part of the author -> commiter -> reviewer series of 
transitions is learning to know what you don't know, i.e. when to ask 
for help and defer to others for more input.

I don't anticipate much hazard in practice from formally adopting 
project-wide rolls to cover all of hotspot, core libs, client libs, 
langtools, etc. I would argue there is too-little rather than too-much 
work and communication across different teams. Code (and code reviews) 
today strongly tend to stay in areas people are familiar with.

-Joe