Looking ahead: proposed Hg forest consolidation for JDK 10

[joe darcy]

Hi Thomas,


On 10/18/2016 7:39 AM, Thomas Stüfe wrote:
> Hi all,
>
> On Mon, Oct 17, 2016 at 2:22 PM, Lindenmaier, Goetz <
> goetz.lindenmaier at sap.com> wrote:
>
>> Hi,
>>
>> I'm on a 1.6 TB share available to our team visible on all our
>> servers. The machine is a 48 processor 64GB linux x86_64 server.
>> The servers only have limited local disc space.  Especially with the
>> new setup I can not have clones on all the machines I need to compile
>> and test on.
>>
>> Best regards,
>>    Goetz.
>>
>>
> I'm on Goetz team at SAP. Just wanted to give some additional information:
>
> I keep reading "use local repos". This is unfortunately not practical for
> us. Limited local disk space on build machines is only the smallest of the
> problems. A bigger problem is our platform breadth.
>
> We have a large zoo of machines running a number of cpu/os combinations.
> When we develop for the OpenJDK, we want to build and test on multiple -
> preferably all - machines and platforms the OpenJDK is supported on, to
> make sure we do not introduce regressions. But we have no automatic build
> system for these platforms, nor do we have access to your jprt.

Independent of what happens with this proposal, I suggest setting up 
some kind of in-house build and test system to help automate such 
procedures. Internally at Oracle, we have various Hudson/Jenkins systems 
in addition to jprt.

> So, as an example the fix for JDK-8166944 I did build on Linux (x64, ppc,
> s390), Solaris (sparc, x64), AIX, MacOS, and Windows x64. I usually leave
> out platforms I think are safe - in this case 32bit and zero - but at my
> own risk, because if I introduce a regression because I do not build, I
> risk the annoyance of other developers.
>
> Therefore local repos are not practical - syncing local repos across many
> machines is a pain and very error prone. So, every developer keeps his
> repos on a filer (NFS) and so if the NFS client on a certain machine is not
> good, we wait and suffer.
>
> So performance matters for us a lot.
>
>

[snip]

Using a particular set of Hg source repositories is not a guaranteed 
interface of the JDK and as a historical note there was some discontent 
with consequences of using more than one repository when the Hg repos 
were first published:

http://mail.openjdk.java.net/pipermail/discuss/2007-December/000505.html

We on the consolidation team are willing to continue exploring options 
to better accommodate differing workflows and system architectures. I 
think it is reasonable for some changes to those systems to be included 
in the space of candidate solutions.

Regards,

-Joe