JDK8 Preliminary Repository Layout

[Kelly O'Hair]

On Mar 10, 2011, at 3:10 PM, David Holmes wrote:

> Kelly O'Hair said the following on 03/11/11 09:00:
>> On Mar 10, 2011, at 2:50 PM, David Holmes wrote:
>>> Lana Steuck said the following on 03/11/11 07:03:
>>>> On 03/10/2011 08:46 AM, Kelly O'Hair wrote:
>>>>> Interesting point, we will need to decide which projects need jdk8 forests. I imagine some will not, and we may be
>>>>> doing a little trimming down on the number of team forests.
>>>> Makes sense. There are some team forests (at least one that I know of) that are not being used, so we can look into removing those and maybe combining those team forests which have more interdependencies into one forest (provided that the team members agree).
>>> I've never been a fan of the "all projects are complete forests". It just increases the conceptual complexity of the repositories and the workload of keeping all the forests sync'ed up. It should be easy to add additional repositories to a project as the need arises, without requiring all repositories.
>>> 
>> But all too often, regressions in one part of the forest only manifest themselves when building the entire forest.
>> So it is the responsibility of the Developer and Integrator to insure the entire forest builds and works prior
>> to integrations into the 'master' (jdk7/jdk7) forest.
>> Integrators are required to sync up with master, test build, and integrate the entire forest, not partials.
> 
> Developers (other than those working on the build system) rarely build forests. Hotspot engineers build hotspot, T&L engineers build jdk etc. The team integrators certainly have to combine with the "master" forest at the next level. But keeping a bunch of unmodified team repos up to date with the "master" is just pure overhead.

Completely disagree. They may be unmodified by one team, but someone IS modifying them, they are ALL
very much moving targets.
But if the Integrators wanted to do it differently, with the same reliability, they certainly have that option.
I have always assumed these full forests existed for the sanity of the Integrators and the protection of the
master always being able to build after an integration.
So the Integrator having a place to keep a full forest on the server, that they controlled when it got sync'd
up with master, and a place to point at and tell a team member, "this forest does not build after your change was pushed"
seemed like a benefit to the Integrator.

Not many people are "Integrators", it's a a bit of a thankless task sometimes, be nice to your Integrators! ;^)

> 
> Maybe hotspot needs a full forest (I don't think so), but certainly hotspot_rt, hotspot_comp and hotspot_gc do not, in my opinion.

The sub-team repos  hotspot_rt, hotspot_comp and hotspot_gc aren't a major concern to me, they never
integrate directly into the master. If you want these to be partial, I'd talk to the person on your team that
can change that.

> 
>> By having that full forest available for the team, you can at least be sure that anyone on the team doing full
>> forest builds is dealing with the same sources.
>> Developers can choose to only use partials, that is certainly always possible.
> 
> If a team operates in such a way that full forest builds are needed then the team will use a full forest. Most of the teams do not need that. Having the forest just creates work for the gatekeeper.

If by "gatekeeper" you mean the person that pushes your sub-team repos to the team repos, hey, that's
your team's decision.

---
And there have been several times in the past, granted not many, where jdk and hotspot changes needed to
made by a hotspot developer. Ask the serviceability team. It's rare, but having them there does have value
to some, rather than a moving target, they can rely on a state that is defined by their team.

-kto

> 
> I said all this when the forest of forests was first devised. As I said never been a fan, don't see the need for it.

> Cheers,
> David
> 
>> -kto