I definitely support this approach: keep the original workflow before the new workflow setup. We have enough time to achieve "THE APACHE WAY" step by step before NuttX graduate to the top level project.
On Tue, Dec 24, 2019 at 8:51 AM Gregory Nutt <spudan...@gmail.com> wrote: > > 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 > >
