Proposal to revise forest graph and integration practices for JDK 9

[Andrew]

----- Original Message -----
> 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.
> 

That sounds like a maintenance nightmare.  Also, I know I for one have probably
committed to most forests at one time or another.  All this grouping seems based
on internal Oracle groups which have no relevance to those of us outside.

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

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07