Proposal to revise forest graph and integration practices for JDK 9

[Jeremy Manson]

Is it worth formalizing the permission system?  That is, only a select
group of people would be allowed to give permission to check into any given
directory, and said permission can be granted by those people to others, on
a change by change basis?

I don't know how to write a Mercurial extension, but I bet someone could
come up with one that allowed a select group of people to provide
permission for a third party to commit a particular changeset to a
directory.  There is already an ACL extension.

Jeremy


On Mon, Nov 25, 2013 at 9:44 PM, Joe Darcy <joe.darcy at oracle.com> wrote:

> 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
>