Proposal: Allowing selective pushes to hotspot without jprt

[Mikael Vidstedt]

Volker,

Thanks for reminding me, this totally slipped my mind.

I think it's fair to say say we've given this enough time for feedback, 
and that the feedback has been all supportive. With that in mind I 
consider the proposal approved and effective immediately!

Cheers,
Mikael

On 2014-11-06 15:35, Volker Simonis wrote:
> 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
>>>>>>>