Hi all, D-Day; I'll go ahead and create the branches.
On Tue, Jun 9, 2020 at 2:42 PM Abdelatif Guettouche <abdelatif.guettou...@gmail.com> wrote: > > > 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
