> I guess the other question I want to know is what is on master that is not > in the release?
There are some git log options that we can use to get that. What we want is to just filter out the cherry-picked commits. I shared this command before: "git log --oneline --cherry-pick --right-only releases/9.0...master" On Tue, Jun 9, 2020 at 1:32 PM David Sidrane <david.sidr...@nscdg.com> wrote: > > I was speaking of git tag, for convenience. > > I guess the other question I want to know is what is on master that is not > in the release? > > If we use git tags: One is dropped on the branch point. One is dropped on > the release point. The delta on master is the full set of commits that came > in to master while the release was happening. The delta (tag to HEAD) on the > release branch is the backports, That will answer the question what is on > master that is not in the release. > > With tags, commit message do not need to say [BACKPORT]. But if they do say > [BACKPORT], all that is needed it the log to know what we back ported. > > I think one giant PR is harder to work with. Many BP PR's is fine just, > titled or git labeled as a back port to release r.m.n would be helpful. If > it is in the Title it will help filter emails. Not sure if the labels are > helpful in an inbox but are on Github. > > Assuming master has testing, bug fix Backport PR should be merged with 0 > delay. > > > David > > -----Original Message----- > From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com] > Sent: Tuesday, June 09, 2020 5:02 AM > To: dev@nuttx.apache.org > Subject: Re: Release 9.1 > > > I'm also not clear are we talking about git tags here or github > > labels? We are using git tags but that is when we cut the release on > > the release branch. > > I don't know why I assumed Github labels and not git tags. I was > obviously talking about Github labels. I'm not sure how David sees > the use of git tags in this context. > > For backporting PRs, I don't mind either solutions, but I also prefer > periodically adding the PRs with the backport prefix and the PR > number. I guess others had some concerns with this, maybe they can > help us understand. > > > On Tue, Jun 9, 2020 at 4:06 AM Brennan Ashton <bash...@brennanashton.com> > wrote: > > > > On Mon, Jun 8, 2020 at 6:21 AM Abdelatif Guettouche > > <abdelatif.guettou...@gmail.com> wrote: > > > > > > > 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? > > > > I liked what we did last release with periodically adding a PR with > > the backported commits. If we just keep one giant PR with the > > backports this will make it harder for people to test the branch. > > For the most part we had the backported PR numbers in the PR title > > which made it really easy to match up later to figure out what did not > > apply to the next release. I don't really have an opinion on the > > matter of if we edit the commit, but I am not sure what the added > > value would be. > > > > I'm also not clear are we talking about git tags here or github > > labels? We are using git tags but that is when we cut the release on > > the release branch. > > > > --Brennan
