On Mon, Jun 15, 2020 at 9:55 AM Matias N. <mat...@imap.cc> wrote: > > Hi, > I wanted to ask about what you think is the best way of working with > nuttx/apps repo for a downstream user considering the new release branching > strategy. > > Previously I was used to having the master branch contain release tags so I > would generally work on top of these tags creating local commits on my > project specific branch, inside a fork of nuttx/apps, if needed. Then, > whenever a new version of NuttX was released, I could rebase my branch to the > new release tag. Moreover, this local branch will usually contain a series of > commits which I intend to upstream (fixes/improvements). To do so, I would > create a branch stemming from master (or, at least, the most recent release > tag) and then cherry-pick these commits there. > To contribute this in the form of PRs I would do this creating one branch for > each PR. At the end of each PR acceptance I can then rebase my main working > branch to the new tip and the rebase would recognize these upstreamed commits > and would not generate any conflicts. In the end, my branch would only > contain non-upstreamed commits. > > Now, I'm facing a problem whereas I would like to work on top of stable > releases but since these are tips of branches that are never merged back to > master, rebasing as previously described introduces many conflicts between > commits which are backported from master to these branches. To me it is > strange that these release branches are never merged and no release tag seems > to exist. Most projects I worked with usually tag release commits and they > are always part of the main history.
There are release tags created: https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.0.0-RC1 > > I'm wondering if maybe there's something I could change in my workflow or > maybe the release branching/tagging strategy could be adapted to ease > downstream work. For example, if there would be something as a feature-freeze > window some time before a release, disruptive PRs (ie: non bug fix PRs) > against master could be held until master is stabilized and released with a > tag. In this scenario I think release branches are not needed, the resulting > history is linear and there are no unmerged tips. The last release was probably not a good indicator of how far the release branch will deviate (there were a lot of backported fixes). But part of the reason it is not feasible to just merge back in is two fold: 1. We want to have these branches for bug fix releases. The last release did not have one, but there likely should have been one for at least one bug that was found related to loading binaries 2. With the Apache release process it takes a long time for releases to get out the door. Once a RC is created it is likely 1-2 weeks before it is actually released. There are two three day voting periods and for example the last release one of those voting periods took a week. We also had to do 2 release candidates each time we do that the clock gets reset. In the mean time a lot of changes are happening in master, even today just after the release branch was created a lot of large changes went into master. What I suspect would actually work well is to change your rebase strategy to instead of rebasing your entire branch (off of release branch), but instead to rebase only your commits onto master or the next release branch: git rebase --onto dest first_commit last_commit With this you would exclude all of the backport commits which are likely the source of the rebase troubles. I hope that helps. --Brennan
