>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.
+1 I think because stable says what it is. Junping suggestion is an excellent one. I am not endorsing this tool, but it is really slick, even just to get the concepts from the video. (in the vedio replace `master` with `stable` with and `development` with master) https://blog.axosoft.com/gitflow/ Some questions to discuss as we move forward (no need for immediate discussion)? What will our Software release life cycle[1] look like? Do we choose to do LTS[2]? Do we do release branching? Do we do backports [3] on to release candidates[1]? Do we do hot fixes[5]? David [1] https://en.wikipedia.org/wiki/Software_release_life_cycle [2] LTS is an abbreviation for “Long Term Support”. [3] https://en.wikipedia.org/wiki/Backporting [4] https://softwareengineering.stackexchange.com/questions/288935/difference-between-hotfix-and-bugfix -----Original Message----- From: 俊平堵 [mailto:junping...@apache.org] Sent: Monday, December 23, 2019 6:27 PM To: dev@nuttx.apache.org Subject: Re: Single Committer bq. I would create a dev branch and expect all PRs to be against that dev branch. 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. Thanks, Junping Gregory Nutt <spudan...@gmail.com> 于2019年12月24日周二 上午8:51写道： > Recent events have made me reconsider some decisions I made. I threw > off the single committer mantle when I saw the abuse of privilege in the > repositories. If the PPMC agrees to it, I will take up that role again. > > But let's be frank. Here is what I think that means: > > * I would be sole committer of changes. The repositories would have > to be treated as read-only just as back in the Bitbucket days. > * I would grandfather in the i.MXRT changes. > * I will decline all workflow related changes until workflow > requirements are established (that is my only real motivation for > suggesting this: To make certain that we have proper requirements > in place before we accept PX4 workflow into our repositories. We > need to do this right and I am willing to protect the repositories > until the workflow requirements are established. I expect that to > take about two weeks.) > * I would create a dev branch and expect all PRs to be against that > dev branch. > * As soon as the PPMC is confident that it has the processes in place > to handle the commit workload I will gladly relinquish this role. > * THIS IS NOT THE APACHE WAY. This is an interim dictatorship role to > expedite the avalanche of commits expected after the holidays. > > If any of this concerns people, please "Just Say No." I am not married > to the idea and I am not forcefully advocating it. This is what people > wanted me to do a few days ago and if I can protect our right to define > the workflow, then I will do it. For me it is a sacrifice that I would > take with no pleasure in. > > Pros: This will provide project continuity until the PPMC is fully > functional. Having workflow requirements will be a huge step in that > direction. People stressed about the commit process can relax with > confidence. This will protect the code base from premature work flow > changes until we have an understanding of what we want. No harm is done > by deferring workflow changes until we as a team are prepared to deal > with them. > > Cons: This is not the Apache way. People who are trying to bulldoze > the PX4 work flow into the repositories will hate the idea. Mentors > will hate the idea. An approach more consistent with the Apache way > would just be to let the chaos prevail. That is fine with me too as > long as we do not let PX4 advocates take away our group right to define > our own workflow. We can still just put all workflow changes on hold > until we have the requirements in hand. > > I am not pushing anything. Think about it and let me know what you > would like to do. > > Greg > > >
