Proposal: Allowing selective pushes to hotspot without jprt

[Volker Simonis]

Hi Mikael,

just wanted to ask what's the status of this project?
I hope it was not just a JavaOne hoax :)

Regards,
Volker


On Fri, Sep 19, 2014 at 8:47 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> Thanks Mikael, that sounds good!
>
> Regards,
> Volker
>
>
> On Fri, Sep 19, 2014 at 8:03 PM, Mikael Vidstedt
> <mikael.vidstedt at oracle.com> wrote:
>>
>> Volker,
>>
>> The proposal is only to change how the changes are pushed, not which forests
>> changes can be pushed to. That is, we would still require hotspot changes to
>> be pushed to one of the group repositories (jdk9/hs-{comp,gc,rt}) or to the
>> jdk8u/hs-dev forest (jdk8u), but I propose that the relaxation be applied on
>> all those (four) forests. Reasonable?
>>
>> Cheers,
>> Mikael
>>
>>
>> On 2014-09-12 11:38, Volker Simonis wrote:
>>>
>>> Hi Mikael,
>>>
>>> there's one more question that came to my mind: will the new rule
>>> apply to all hotspot respitories (i.e. jdk9/hs-rt/hotspot,
>>> jdk9/hs-comp/hotspot, jdk9/hs-gc/hotspot, jdk9/hs-hs/hotspot AND
>>> jdk8u/jdk8u-dev/hotspot, jdk8u/hs-dev/hotspot) ?
>>>
>>> Thanks,
>>> Volker
>>>
>>>
>>> On Thu, Sep 11, 2014 at 12:16 AM, Mikael Vidstedt
>>> <mikael.vidstedt at oracle.com> wrote:
>>>>
>>>> Andrew/Volker,
>>>>
>>>> Thanks for the positive feedback. The goal of the proposal is to simplify
>>>> pushing changes which are effectively not tested by the jprt system
>>>> anyway.
>>>> The proposed relaxation would not affect work on other infrastructure
>>>> projects in any relevant way, but would hopefully improve all our lives
>>>> significantly immediately.
>>>>
>>>> Cheers,
>>>> Mikael
>>>>
>>>>
>>>> On 2014-09-10 01:45, Volker Simonis wrote:
>>>>>
>>>>> Hi Mikael,
>>>>>
>>>>> thanks a lot for this proposal. I think this will dramatically
>>>>> simplify our work to keep our ports up to date! So I fully support it.
>>>>>
>>>>> Nevertheless, I think this can only be a first step towards fully open
>>>>> the JPRT system to developers outside Oracle. With "opening" I mean to
>>>>> allow OpenJDK commiters from outside Oracle to submit and run JPRT
>>>>> jobs as well as allowing porting projects to add hardware which builds
>>>>> and tests the HotSpot on alternative platforms.
>>>>>
>>>>> So while I'm all in favor of your proposal I hope you can allay my
>>>>> doubts that this simplification will hopefully not push the
>>>>> realization of a truly OPEN JPRT system even further away.
>>>>>
>>>>> Regards,
>>>>> Volker
>>>>>
>>>>>
>>>>> On Tue, Sep 9, 2014 at 11:24 PM, Mikael Vidstedt
>>>>> <mikael.vidstedt at oracle.com> wrote:
>>>>>>
>>>>>> All,
>>>>>>
>>>>>> Made up primarily of low level C++ code, the Hotspot codebase is highly
>>>>>> platform dependent and also tightly coupled with the tool chains on the
>>>>>> various platforms. Each platform/tool chain combination has its set of
>>>>>> special quirks, and code must be implemented in a way such that it only
>>>>>> relies on the common subset of syntax and functionality across all
>>>>>> these
>>>>>> combinations. History has taught us that even simple changes can have
>>>>>> surprising results when compiled with different compilers.
>>>>>>
>>>>>> For more than a decade the Hotspot team has ensured a minimum quality
>>>>>> level
>>>>>> by requiring all pushes to be done through a build and test system
>>>>>> (jprt)
>>>>>> which guarantees that the code resulting from applying a set of changes
>>>>>> builds on a set of core platforms and that a set of core tests pass.
>>>>>> Only
>>>>>> if
>>>>>> all the builds and tests pass will the changes actually be pushed to
>>>>>> the
>>>>>> target repository.
>>>>>>
>>>>>> We believe that testing like the above, in combination with later
>>>>>> stages
>>>>>> of
>>>>>> testing, is vital to ensuring that the quality level of the Hotspot
>>>>>> code
>>>>>> remains high and that developers do not run into situations where the
>>>>>> latest
>>>>>> version has build errors on some platforms.
>>>>>>
>>>>>> Recently the AIX/PPC port was added to the set of OpenJDK platforms.
>>>>>> From
>>>>>> a
>>>>>> Hotspot perspective this new platform added a set of AIX/PPC specific
>>>>>> files
>>>>>> including some platform specific changes to shared code. The AIX/PPC
>>>>>> platform is not tested by Oracle as part of Hotspot push jobs. The same
>>>>>> thing applies for the shark and zero versions of Hotspot.
>>>>>>
>>>>>> While Hotspot developers remain committed to making sure changes are
>>>>>> developed in a way such that the quality level remains high across all
>>>>>> platforms and variants, because of the above mentioned complexities it
>>>>>> is
>>>>>> inevitable that from time to time changes will be made which introduce
>>>>>> issues on specific platforms or tool chains not part of the core
>>>>>> testing.
>>>>>>
>>>>>> To allow these issues to be resolved more quickly I would like to
>>>>>> propose
>>>>>> a
>>>>>> relaxation in the requirements on how changes to Hotspot are pushed.
>>>>>> Specifically I would like to allow for direct pushes to the hotspot/
>>>>>> repository of files specific to the following ports/variants/tools:
>>>>>>
>>>>>> * AIX
>>>>>> * PPC
>>>>>> * Shark
>>>>>> * Zero
>>>>>>
>>>>>> Today this translates into the following files:
>>>>>>
>>>>>> - src/cpu/ppc/**
>>>>>> - src/cpu/zero/**
>>>>>> - src/os/aix/**
>>>>>> - src/os_cpu/aix_ppc/**
>>>>>> - src/os_cpu/bsd_zero/**
>>>>>> - src/os_cpu/linux_ppc/**
>>>>>> - src/os_cpu/linux_zero/**
>>>>>>
>>>>>> Note that all changes are still required to go through the normal
>>>>>> development and review cycle; the proposed relaxation only applies to
>>>>>> how
>>>>>> the changes are pushed.
>>>>>>
>>>>>> If at code review time a change is for some reason deemed to be risky
>>>>>> and/or
>>>>>> otherwise have impact on shared files the reviewer may request that the
>>>>>> change to go through the regular push testing. For changes only
>>>>>> touching
>>>>>> the
>>>>>> above set of files this expected to be rare.
>>>>>>
>>>>>> Please let me know what you think.
>>>>>>
>>>>>> Cheers,
>>>>>> Mikael
>>>>>>
>>