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. > >
