+1 On Tue, Dec 24, 2019 at 5:18 AM Alan Carvalho de Assis <acas...@gmail.com> wrote:
> +1 > > On Monday, December 23, 2019, 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 > > > > > > > -- Adam Feuer <a...@starcat.io>
