On Tue, 27 Oct 2020 06:35:33 GMT, Aleksey Shipilev <[email protected]> wrote:
>>> > My rationale is simple: I am playing the whack-a-mole against the ongoing >>> > x86_32 regressions here >>> >>> Would it be possible that we add a Travis hook so that commits get tested >>> once before they are merged? >> >> Maybe, but that would be beyond the scope of this PR. These GH actions >> workflows go the long way already to make pre-integration tests, and they >> already run and used by OpenJDK contributors. I see immediate value in >> improving GH workflows, and see no clear estimate how much work would be >> involved in hooking up Travis, and what the project-wide consequences would >> be. If you want, open a new bug, prototype the change, discuss it there, and >> see if that is an acceptable thing to do. > > Let me coop this PR to rename x32 -> x86, among other cosmetic changes. Once > #830 lands, I'll update x32 -> x86 in those new blocks as well. This way, we > can have best of both worlds: x86_32 would start testing, and we would do the > follow-ups here. > @shipilev I realize you are eager to have Github run automatic testing on > platforms that you care about, but it's not like it's a regression that needs > to be taken care of immediately. I strongly prefer to have a correct solution > implemented once, before committing, than this piece-meal splitting of what's > actually a single issue into three different PRs. I very much care that the in-flight PRs (notably #505 and #548) would get their x86_32 testing early, hopefully before their integration. Because, having the same argument here, I strongly prefer to have a correct solution implemented once for the *actual product code*. I believe the choice between "making the test code sparkling clean in one go" and "making the product code sparking clean in one go" is obvious. > Now, the first one has already gone in, so not much to do about that, but I > strongly believe that this and JDK-8255305 should be folded together in a > single issue. I disagree. These changes are logically independent. #830 adds testing step, it is self-sufficient, already tested, and already in review. This one cleans up cosmetics, is relatively new, has a potential to accumulate other followups, and thus risks to drag on. Let's do the MVP in #830, and then do everything else. ------------- PR: https://git.openjdk.java.net/jdk/pull/869
