Proposal to revise forest graph and integration practices for JDK 9

[Andrew]

----- Original Message -----
> On Tue, Nov 26, 2013 at 9:43 AM, Andrew <gnu.andrew at redhat.com> wrote:
> 
> > ----- 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.
> >
> 
> Presumably, such a system would have more to do with OpenJDK membership
> than Oracle groupings.
> 

Maybe I misunderstood what you were saying, but I took it as meaning there would
be different explicit permissions for e.g. 2d, swing, tools, hotspot, etc.
The way the repositories and OpenJDK groups are split up is largely reflectively
of internal structure inside Oracle, as far as I understand it, so while a developer
there may only ever work on code under 2d, I tend to end up making commits wherever
bugs are found; one day it may be a HotSpot issue, the next a build problem in the JDK, etc.

> One big benefit of being able to check in code anywhere is that you can do
> global cleanups (warnings and the like) across the entire codebase without
> getting permission from everyone.  One big drawback is that if a team has a
> rigorous test that they want to run before any checkin (I believe that
> Hotspot has some non-open tests they like to run before non-trivial
> changes), then having other people able to make changes to their code base
> without running those tests may cause some pain.
> 

I think, as Mark says, it works better based on trust than on trying to solve such
social issues with technical fixes.

> I suppose that the main question is, with a 10MLOC codebase, and scores of
> developers, do you trust everyone with a committer bit to do the right
> thing all of the time?  The answer might very well be yes.
> 

I think it is.

> Jeremy
> 

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