Proposal: Allowing selective pushes to hotspot without jprt

[Volker Simonis]

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