Hi Greg,
I have tried to answer some of your questions. See below: >-----Original Message----- >From: Gregory Nutt [mailto:spudan...@gmail.com] >Sent: Tuesday, December 24, 2019 6:48 AM >To: dev@nuttx.apache.org >Subject: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer) >>> An alternative way could be make master/trunk branch a dev branch and allow >>> all PRs to checked in, at the same time, maintain a stable branch which you >>> can cut release (as release manager) and pick up PRs that you carefully >>> reviewed. - This is the Apache way and I guess can achieve the same goal. >That would simplify accepting PRs since the uniformed will probably >continue to submit against master. *[DBS] The default branch is set-able * >This would make that behavior >workable. Semantically, I would have to wrap my head around the notion >that the master is not the master but a development branch. But even >old dogs can learn new tricks with enough time. >I can see how this works well into a release strategy. But what about >uses who want to work from clones or forks? >I have some doubts: If an an end-user clones or forks the change, it >would still default to creating only the master branch. *[DBS] No. It is a clone\fork of ALL the branches in the repo.* *This was a fork:* *[image: cid:img003.jpg@01D5BA3A.F15D7100]* >You would want users working on the master branch, you would want them to be >working in the stable branch. There could potentially bad changes on the master. *[DBS] It is their choice to be on the Bleading edge or a stable offshoot* *We will have give tools some special consideration because of this - a release will have a older copy of nxstyle* >Is there a way to force the initial branch to be the stable branch instead of master. *[DBS] Yes but that is not the way it should be done as the default branch is what the PR will default against. * *In this case development is our master and master should be the default.* >If they make changes that they want to submit on the stable branch >branch, it seems to me that you have essentially the same communication >problem. They would need to transfer their changes to the master branch >before creating the PR. Is that right? *[DBS] Nope - if say we have release-nuttx-9.2.0 released branch and they have a fix on it.* *They have a PR against nuttx-9.2.0 (but is branch protected) We can discuss the change and start a new branch nuttx-9.2.1-RC00 and then have them move the PR there * *we can do it ourselves. Pull the PR to you local repo (see githup command line on Pr) then push to nuttx-9.2.1-RC00* *This is the why naming matters.* *[DBS] Most git users understand the default work flow, but a README.MD could offer the correct* *choice of Branches and work flow (as can a .gitmodules when set up correctly) but deviating from the norms* *Is NOT a good idea as it will cause issues for everyone.* >Another nit and this is just probably due to my fumble fingers: I often >get weird things happening when I add changes to branches, then squash >them into the stable branch (master in this case). *[**DBS] Use the github in chrome (WEBUI) - it make the job simple: to update a branch, rebase, and merge. It also has a directions to do it on the command line correctly.* >At that point the histories of the two branches have diverged. I can usually reuse the >old branch by rebasing and pushing the branch with --force. But the >history will still not be 100% the same as the stable branch. If I lose >confidence in the content of a development branch (which is fairly >often), I usually just delete the branch and recreate it clean. But we >cannot do that if master is the stable. We can't delete master can we? >There are ways to force to branches to be identical (in both content and >history) but I would have to get used to doing that. *[DBS] You can choose to use branch rebase work flow - it will be == [source branch] + Just your changes on top.* *Interactively rebase it (rebase -i master and clean it up) * *- it will dump the merge commits on your branch - we want to avoid them.* *see mv-changes *https://github.com/MikhailGolubtsov/git-mv-changes *Force push:* *1) Only to your own braches (I always fetch and check the remote) or just rebase on it.* *2) Only on a shared branch after coordination with the team. Ask them to push all their commit then (Do 1 above)* * Clean it up force push. The raise the "All clear"* *3) Never force push to master. It should be branch protected. * >It seems that this strategy adds some nice simplifications in one area >but at least raises some questions in others. Perhaps GIT power users >could answer all of those questions (but let's place not clutter up the >list by solving the full workflow here. Please contribute your thoughts >directly as comments at > https://cwiki.apache.org/confluence/display/NUTTXTEST/Code+Contribution+Workflow+--+Brennan+Ashton ). I hope this helps David
