Proposal: Allowing selective pushes to hotspot without jprt

[Andrew Hughes]

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

+1

The build-test-commit idea works fine.. if a) it actually tests the platforms
relevant to the fix and b) it's accessible to everyone involved in the project.
For those of us outside Oracle working on platforms other than x86, x86_64 and
sparc, neither a or b is true.

As a case in point, "7141246: build-infra merge: Introduce new JVM_VARIANT* to 
control which kind of jvm gets built" was committed, having passed jprt. However,
it primarily made changes to the builds for Zero and Shark, which jprt doesn't
test, and subsequently broke them. For me to then fix it, in "8024648: 7141246 & 
8016131 break Zero port", meant finding someone to both review that change and
run it through jprt. Due to the way things are frozen, I believe it's still
broken in u40.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07