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 wrote: > > On Mon, Jun 8, 2020 at 6:21 AM Abdelatif Guettouche > 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
RE: Release 9.1
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 wrote: > > On Mon, Jun 8, 2020 at 6:21 AM Abdelatif Guettouche > 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
Re: Release 9.1
> 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 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 > wrote: > > > > On Mon, Jun 8, 2020 at 6:21 AM Abdelatif Guettouche > > 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
