RFR: 8255412: "Linux x32" should be "Linux x86" in submit workflow
Magnus Ihse Bursie
ihse at openjdk.java.net
Tue Oct 27 09:25:21 UTC 2020
On Tue, 27 Oct 2020 08:53:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> 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.
Do you mean that you consider #505 and #548 dependent on this bug? If so, I think you misunderstand the purpose of the Github submit testing hook. You can -- and should! -- still do proper testing just as you did before the migration to Github. The Github action hook is a convenience.
Unless there is a breakage or a regression, I don't think we should rush patches in. It's better to get things right. You say "then do everything else". Are there more functionality regarding x86 that you would like to see integrated in the Github submit hook? If so, I think it's better that you present it now, than just a piece at a time.
> 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.
I don't even understand what you mean by this.
> These changes are logically independent.
No, they are not. For one thing, this patch would explicitly introduce the "x32" naming, something JDK-8255305 is set. to remove. And this is just a trivial indication that both issues revolves around giving proper support for x86 in the submit flow.
Just to be clear: I do not object to making x86 a first-class citizen in the submit hook! What I *do* object to is this piece-meal integration of two, or worse, three, PRs for what should have been one comprehensive PR.
-------------
PR: https://git.openjdk.java.net/jdk/pull/869
More information about the build-dev
mailing list