There is no merge-then-review. The work has been reviewed. This is identical to how reviews work as normal.
If it helps your mental model, consider this a convenient atomic merge of many Jira that have independently met the standard project procedural requirements, as that is what it is. Squashing of commits is normal before merging a ticket, and does not typically incur an additional round of review - indeed, it’s not even clear what this would mean, since a squash has no visible effect to review. This is not a question of moving fast, but a question of process. We have out of politeness highlighted the impending merge of a lot of work. This is an invitation to engage on the relevant tickets that already exist to represent the work, not an invitation to create novel adhoc procedural steps. > On 23 Jan 2023, at 22:54, Mick Semb Wever <m...@apache.org> wrote: > > >> The sooner it’s in trunk, the more eyes it will draw, IMO, if you are right >> about most contributors not having paid attention to a feature branch. > > > > We all agree we want the feature branch incrementally merged sooner rather > than later. > IMHO any merge to trunk, and any rebase and squash of ninja-fix commits, > deserves an invite to reviewers. > Any notion of merge-then-review isn't our community precedent. > > I appreciate the desire to not "be left hanging" by creating a merge ticket > that requires a reviewer when no reviewer shows. And the desire to move > quickly on this. > > I don't object if you wish to use this thread as that review process. On the > other hand, if you create the ticket I promise to be a reviewer of it, so as > not to delay. > >
