r275282 added fast-cq mode (for landing patches quickly through commit-queue by skipping building and testing). We should webkit-patch support for fast-cq mode. webkit-patch should have a --fast-cq parameter, which would result in uploaded patch being appropriately named on Bugzilla to trigger fast-cq mode.
Created attachment 425409 [details] Patch
Created attachment 425411 [details] [fast-cq] Patch
This seems fine to do, but I don't really understand the goal. I understand that everything will be landed via commit queue on GitHub. But what exactly will we achieve by encouraging people to use CQ more now? Are you expecting that we'll still be using patch based workflow, so we need to find and fix all svn-apply bugs and limitations?
(In reply to Alexey Proskuryakov from comment #3) > This seems fine to do, but I don't really understand the goal. I understand > that everything will be landed via commit queue on GitHub. But what exactly > will we achieve by encouraging people to use CQ more now? Are you expecting > that we'll still be using patch based workflow, so we need to find and fix > all svn-apply bugs and limitations? This comment seems more about Bug 223942. fast commit queue mode would be useful even in git world, since there would be various scenarios in which people would want to land quickly or skip building/testing, e.g.: build fix, typo fix, minor follow-up fix. For example, I just used this --fast-cq parameter to upload a patch for small follow-up fix in https://bugs.webkit.org/show_bug.cgi?id=223686#c14. I will discuss the concerns about Bug 223942 separately.
Committed r275672 (236308@main): <https://commits.webkit.org/236308@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 425411 [details].
<rdar://problem/76417274>