No, that is not the normal process. What is it you think you would be reviewing? There are no diffs produced as part of rebasing, and the purpose of review is to ensure code meets out standards, not that the committer is competent at rebasing or squashing. Nor are you familiar with the code as it was originally reviewed, so would have nothing to compare against. We expect a clean CI run, ordinarily, not an additional round of review. If we were to expect that, it would be by the original reviewer, not a third party, as they are the only ones able to judge the rebase efficiently.
I would support investigating tooling to support reviewing rebases. I’m sure such tools and processes exist. But, we don’t have them today and it is not a normal part of the review process. If you want to modify, clarify or otherwise stipulate new standards or processes, I suggest a separate thread. > How will the existing tickets make it clear when and where their final merge > happened? By setting the release version and source control fields. > On 24 Jan 2023, at 08:43, Mick Semb Wever <m...@apache.org> wrote: > > >> .... But it's not merge-than-review, because they've already been reviewed, >> before being merged to the feature branch, by committers (actually PMC >> members)? >> >> You want code that's been written by one PMC member and reviewed by 2 other >> PMC members to be put up for review by some random 4th party? For how long? > > > It is my hope that the work as-is is not being merged. That there is a rebase > and some trivial squashing to do. That deserves a quick check by another. > Ideally this would be one of the existing reviewers (but like any other > review step, no matter how short and trivial it is, that's still an open > process). I see others already doing this when rebasing larger patches before > the final merge. > > Will the branch be rebased and cleaned up? > How will the existing tickets make it clear when and where their final merge > happened? >
