Proposal: Allowing selective pushes to hotspot without jprt
Volker Simonis
volker.simonis at gmail.com
Fri Sep 19 18:47:03 UTC 2014
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
>>>>>
>
More information about the hotspot-dev
mailing list