On Thu, 12 Nov 2020 10:08:39 GMT, Volker Simonis <simo...@openjdk.org> wrote:
>>> I'm not at all sure I want to accept these changes. I understand that you >>> care about these exotic platforms, and so do I, but adding them to the >>> submit workflow for _all_ changes seem like the wrong way to proceed. >> >> I understand the first reaction, but please read the updated description. It >> includes the discussion what bugs it tries to catch, and updated cost >> estimates. >> >> Submit workflow is a convenience thing for better testing coverage. Having >> the early warnings for fixable issues in foreign architectures helps to >> avoid follow-up churn without increasing the costs all too much. Do note >> that it does not require contributors to fix the runtime issues in foreign >> architectures, it only asks for passing a rather low bar of _not breaking >> the builds_ for them, which is, in my experience, an easily achievable goal. >> It is easily achievable because -- I am speaking from experience of fixing >> a lot of them over the years! -- the overwhelming majority of arch-specific >> build breakages are about silly things that are obvious from the build logs. >> >> So I am leaving this PR open, letting others to chime in. If there is really >> a need for a wider discussion here, I could start a thread at jdk-dev@, but >> so far it does not look as a good use of our collective time. Please read >> through the description, and see if that soothes your concerns. >> >> Aside: the issues about costs were [raised >> before](https://mail.openjdk.java.net/pipermail/skara-dev/2020-October/003581.html), >> but I think all of them resolve as "enjoy your free tier". If we target to >> optimize the GH action costs, IMO we should instead consider to avoid >> triggering them on every push, as [I hinted >> before](https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004739.html), >> and which I think requires better Skara integration (i.e. for `/test` >> command). Meanwhile, this PR gives us extended build coverage at fraction of >> the additional cost. > > I think this is a really useful feature and I'm a little surprised that it > gets rejected. Please find my comments inline. > >> Aleksey, >> >> I'm not at all sure I want to accept these changes. I understand that you >> care about these exotic platforms, and so do I, but adding them to the >> submit workflow for _all_ changes seem like the wrong way to proceed. >> >> My concern vary all the way from increased build time, to increased usage of >> the Github CPU quota (which, as I understand it, is fairly large but not >> unlimited), to the elephant in the room: the question on who the burden lays >> to fix bugs in these exotic platforms. It is not at all obvious that these >> builds should be tested before commit. >> > > I think "on who's the burden to fix issues" on *exotic* platforms and > "testing changes on all platforms" at commit time are two totally distinct > questions. While I agree that problems on a *exotic* platform shouldn't block > reviewed changes for an unreasonable amount of time, I also think it is very > valuable for both, authors of changes and maintainers of *exotic* platforms > to at least get early notifications of problems on other platforms. > > My experience as a maintainer of the AIX7PowerPC/s390 ports has always been > very positive with regards to the collaboration with authors of changes which > impact these ports. Authors are anxious to not break other platforms but > usually don't have the possibility to test on these platforms. Aleksey's > change comes in very handy here. It will help authors to fix trivial build > problems right in their initial submission which I'm sure they'll appreciate. > For more complex problems it gives Authors the possibility to notify port > maintainers early, before a change gets pushed. I'm sure this alerting could > even be automatized in the future if builds/tests fail on certain platforms. > > Of course such problems shouldn't block changes which are otherwise reviewed > and ready to push for an unreasonable amount of time, so I have nothing > against making the test on such platform optional submit requirements. > > But overall I think Aleksey's enhancement are a great means to improve the > development experience and to keep the OpenJDK repos clean of trivial > follow-up fixes. > > > PS: I specially emphasized *exotic platforms* because it seems to me that > your comment implies that all not Oracle-supported platforms are considered > *exotic* for you. I think in an open source project it should be decided by > the community which platforms are considered *main* (or *primary*) and which > are considered *secondary* platforms. > >> I think this change warrants a much wider and deeper discussion about the >> purpose of the Github commit hook actions, how the free Github CPU quota >> should be spent, and on whom the responsibility lays to either make sure no. >> commit is pushed that breaks an exotic platform, or to rectify the problem >> with a follow-up issue. >> > > I agree that we should we frugal with resources, especially if these > resources are being offered to us at no charge. But from my understanding, > the resources for GitHub actions are accounted on a personal account base for > every developer and not to the upstream project. So every developer who > clones OpenJDK and submits changes to his fork will use his personal "GitHub > Actions" budget. According to [the > documentation](https://docs.github.com/en/free-pro-team@latest/actions/reference/usage-limits-billing-and-administration#usage-limits) > and [@rwestberg's explanations on > skara-dev](https://mail.openjdk.java.net/pipermail/skara-dev/2020-October/003581.html) > this budget contains 20 parallel jobs (with up to 6 hours runtime) 24/7. > Even with Aleksey's changes I think we're well in this budget. > > Are you afraid tha GitHub/Microsoft will cut down this free-tier in general > or for for OpenJDK users? If that's the case we should probably try to get an > offical statement from GitHub/Microsoft on this topic before unnecessarily > restricting ourselves. > > As Aleksey explained, the additional builds should still finish before the > corresponding Windows/MacOS builds and tests terminate, so there shouldn't be > any usability issue either. > >> I recommend you withdraw this PR and instead initiate a wider discussion on >> a suitable mailing list, e.g. jdk-dev. > > I really like this change and I'd appreciate if we could get it merged. I'm > of course always open to discussion on details (e.g. if the new biuilds/tests > should be mandatory or. optional, how to notify port maintainers, etc...). The change to only build hotspot is good. It alleviates some of my concern over this patch. I still think there is a wide difference in how different contributors view these Github Actions submit hooks. Some would never consider to push anything that is not green everywhere, while you think it could be okay to push with broken platform if it takes an unreasonable amount of time to fix. I do think we need to align ourself as a community on how to relate to these submit hook tests. Perhaps getting some ground rules down in the new Developer's Guide, if we can agree on such ground rules. (It's not like there's an old history of oral tradition on how to do things that needs to be written down like the rest of the Guide, it's more like we decide now on how to deal with them.) Finally, I'm worried about reproducibility and debuggability of the Github Actions. We've seen that Github Actions can be updated right under our feet, and have already had trouble with that. And if the logs are not enough, there is no simple way to reproduce the build environment locally do examine the situation. But these are general concerns about the Github Actions themselves, and not specifically aimed at this patch. And I've initiated an off-list discussion on how we can try to address some of these issues. ------------- PR: https://git.openjdk.java.net/jdk/pull/1147
