Proposal to revise forest graph and integration practices for JDK 9

[Jim Laskey (Oracle)]

I'd suggest getting rid of the nashorn forest (which is at the end of the food chain) and go to tl directly except for the fact that all of the nashorn team would have to be reviewers (we double review each others work.)  Seems unlikely, and we're stuck with the current back and forth merges.

-- Jim


On Nov 25, 2013, at 7:36 AM, David Holmes <David.Holmes at oracle.com> wrote:

> On 25/11/2013 8:10 PM, Alan Bateman wrote:
>> On 25/11/2013 08:50, David Holmes wrote:
>>> 
>>> Again I disagree. To me the biggest flaw with the JDK roles are that
>>> they are all encompassing - commiters can commit anything; reviewers
>>> can review anything. At least the projects (jdk8, hsx) provided some
>>> order on this so that generally library folk had roles related to
>>> library code and hotspot folk had roles related to hotspot code.
>>> Removing that distinction would be a step backwards to me.
>> I don't understand this as you'd need 20+ merit badges to cover the
>> breath of the JDK.
> 
> Obviously we're not going to go to that extent, but a single merit badge doesn't cut it either.
> 
>> Instead I would say that it is better to just trust
>> people to do the right thing. That is, is seems unlikely a Committer
>> would propose a patch to the register allocator (for example) on the
>> beans-dev list and get a Reviewer that isn't smart enough to make sure
>> that the hotspot compiler list is consulted. Clearly there will be
>> mistakes made periodically, but that is no different to today. There's
>> nothing like breaking something and getting balled out on a mailing list
>> to learn a lesson.
> 
> But what you are describing is not rule based at all, so we are relying on people to do the right thing. In which case why do we need any roles or rules? If we know hotspot changes need hotspot reviewers then something should formalize that requirement - as it does today.
> 
> David
> 
>> -Alan.
>> 
>>