>> What is the goal of this proposal? > > The goal is to increase the stability of the build
Is this goal distinct from preventing regressions from landing? If so, how? > , speed up EWS by preventing regressions from landing What are some notable cases of recent regressions that have landed because of non-use of commit queue and caused serious problems? Do you have any data on how frequent such regressions are, compared to the base rate of regressions that have landed despite use of commit queue? Do you have any data on how frequently regressions are resolved by patches that land outside commit queue? > and reduce demands of post-commit test gardening. Is this goal distinct from preventing regressions from landing? If so, how? >> What problem are you trying to solve, and with what level of urgency? > > Urgency is not high. I started this with the expectation it would be a > somewhat long and contentious discussion. The motivating change is that the > GitHub transition makes this proposal possible, from a technical perspective, > in a way it is not while the project is still backed by Subversion. I don’t understand the premise here. There are lots of ways to enforce commit policy on a Subversion repository. On the meta level, while we are still dealing with serious regressions in our workflow caused by git and GitHub, I recommend that we do not push forward with more unrelated sweeping changes to the project and its workflow. Just like in software development, where we need to fix regressions before we can move forward with major feature work, so too in tooling we need to do the same. Otherwise we just pile chaos on top of chaos, and there is no way to know if things are improving or getting worse, and no way to hold ourselves accountable for improvement. Thanks, Geoff > > Jonathan > >> >> Thanks, >> Geoff >> >> >>> On Jun 2, 2022, at 2:35 PM, Jonathan Bedard via webkit-dev >>> <webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>> wrote: >>> >>> As we move to GitHub, I would like to propose we strengthen our protections >>> on `main` by making MergeQueue and CommitQueue mandatory. This would mean >>> that with a few exceptions, all changes would need to be built and run >>> layout tests before they are landed. To spell out what the exceptions I had >>> in mind are: >>> >>> - Revert commits, identified by a commit message that starts with >>> “Unreviewed, revering…” would be exempt >>> - Changes which only modify files that do not effect building or testing >>> WebKit would be exempt. These files specifically are: >>> .github/ >>> JSTests/ >>> ManualTests/ >>> metadata/ >>> PerformanceTests/ >>> Tools/ >>> CISuport/ >>> EWSTools/ >>> WebKitBot >>> Websites/ >>> - Emergency build and infrastructure fixes, identified by a commit message >>> that starts with “Emergency build fix” or “Emergency infrastructure fix” >>> would be exempt >>> - A reviewer who is not the commit author can overwrite this protection by >>> adding `unsafe-merge-queue` instead of the commit author >>> - Changes which passed an EWS layout test queue within the last 7 days >>> would skip the layout test check >>> >>> These exceptions are designed to provide contributors for a way to by-pass >>> potentially slow checks if extraordinary situations, or in ones where CI >>> has already validated the change. I think we should keep the ability for >>> any committer to deploy an emergency fix, because our project has many >>> contributors in different timezones and with different holiday schedules. >>> >>> We know that this policy change would potentially slow down development, so >>> I think these 3 improvements block making MergeQueue and CommitQueue >>> mandatory: >>> >>> - run-webkit-tests consulting results.webkit.org >>> <http://results.webkit.org/> to avoid retrying known flakey or failing tests >>> - Another MergeQueue bot >>> - Xcode workspace builds to speed up incremental builds >>> >>> Jonathan Bedard >>> WebKit Continuous Integration >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
