Hi, Michael and Haiting, Thanks for your suggestions, I’ve updated the PR, PTAL.
Thanks, Yunze > On Sep 8, 2022, at 14:41, Haiting Jiang <jianghait...@gmail.com> wrote: > > Good point, Michael. > > Compile errors happen quite often when cherry-picking commits, even > though there is no conflict > but compile still may fail due to some dependency PR missing, or when > we try to resolve some > simple conflicts. > > Thanks, > Haiting > > On Thu, Sep 8, 2022 at 2:26 AM Michael Marshall <mmarsh...@apache.org> wrote: >> >>> If the PR can be cherry-picked directly, we should also check the >>> CI status of the branch after we push them directly. >> >> In order to catch basic compilation or checkstyle errors, I always run >> the following before pushing a cherry picked commit to an upstream >> branch: >> >> mvn -Pcore-modules,-main -T 1C clean install -DskipTests -Dspotbugs.skip=true >> >> Running the check on your machine can be especially helpful when CI is >> backed up or when you want to apply many commits. >> >> Thanks, >> Michael >> >> On Wed, Sep 7, 2022 at 6:35 AM Yunze Xu <y...@streamnative.io.invalid> wrote: >>> >>> Good suggestion. I will update in the PR soon. >>> >>> Thanks, >>> Yunze >>> >>> >>> >>> >>>> On Sep 6, 2022, at 15:46, Haiting Jiang <jianghait...@gmail.com> wrote: >>>> >>>> There are a lot of work before current release process, maybe we should >>>> also include these: >>>> >>>> 1. Start a discussion on the mail list about the release. We can provide a >>>> template to include more clear info about opening PRs and PRs to be >>>> cherry-picked to the released branch. >>>> >>>> 2. Handling all the opening PRs and PRs to be cherry-picked. >>>> >>>> 2.1 Revisit the PR if it should be ported to the released branch. The >>>> release label may not be correct. >>>> >>>> 2.2 Cherry-pick merged PR to the released branch. If there are too many >>>> conflicts, we can ask the PR author to open a new PR to the released >>>> branch. If the PR can be cherry-picked directly, we should also check the >>>> CI status of the branch after we push them directly. >>>> >>>> 2.3 It would be better if we have a clear time window that we should wait >>>> until we postpone the PR to the next release. >>>
