Proposal to revise forest graph and integration practices for JDK 9

[Joe Darcy]

On 11/25/2013 10:37 PM, Jeremy Manson wrote:
> 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?

Before any such system is formalized, a precursor would just be 
documenting the reviewers that should be involved in particular 
areas,"Changes in crypto need Alice's or Bob's review," etc. IIRC, there 
have been some partial efforts on this front previously. My impression 
is that usually the right reviews happen, but that it can take a while 
and it is not always clear who should be asked.

-Joe

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