> Would tags do the same thing? > How does this work over time? > Many PRs or keep force pushing to the PR
For each release there will be only one PR that hosts all the backported commits. And yes, tags would work I guess, it's easy to filter PRs with tags on Github. > How about use cherry-pick -e and add the prefix [BACKPORT] on the back > ported commits. We did something similar for PRs in the last release. Is the purpose to be able to filter out the backported commits later? On Mon, Jun 8, 2020 at 1:27 PM David Sidrane <david.sidr...@nscdg.com> wrote: > > Would tags do the same thing? > How does this work over time? > Many PRs or keep force pushing to the PR? > > How about use cherry-pick -e and add the prefix [BACKPORT] on the back > ported commits. > > -----Original Message----- > From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com] > Sent: Monday, June 08, 2020 5:03 AM > To: dev@nuttx.apache.org > Subject: Re: Release 9.1 > > Should we continue triaging PRs during the 7th-15 period? > Then we stop and only backport what's necessary when the branch is > created (i.e. 15th)? > > I also want to reiterate the backporting procedure. Xiang was > suggesting to create only one PR with all the commits cherry-picked. > GIT wise we will always have the same amount of commits, but this > could help to pinpoint where all the cherry-picked commits are and > come in handy during the next release to separate the backported PR. > > > On Mon, Jun 8, 2020 at 5:20 AM Brennan Ashton <bash...@brennanashton.com> > wrote: > > > > On Wed, Jun 3, 2020 at 2:12 PM Abdelatif Guettouche > > <abdelatif.guettou...@gmail.com> wrote: > > > Generating release notes is the part that has the most painful work, > > > it took 4 of us last time to get it done. I still wonder if there is > > > a way to automate that, maybe with good PR summaries and consistent > > > labeling. > > > Nathan created a confluence page to prepare release notes for the 9.1 > > > ahead of time. > > > > Alright now that we at least have a draft of the release notes for > > both the OS and Apps I would propose this timeline: > > June 7-15th - Focus on stabilizing and any outstanding features that > > we can close out > > June 15th - Create the release branch 9.1 and ask for testing on that > > branch and refine the release notes > > June 22th - Cut RC0 and put it up for a vote to PPMC, if people are > > feeling comfortable with the level of testing we can move this up, but > > let's really try to get some testing in. > > June 25th-27th - (Approximately assuming RC passes) put the RC up for > > a vote to IPMC > > > > I am happy to drive this forward. > > > > --Brennan
