+1 the old way of working was ok but this will put pressure on Greg again. We should define the workflow as soon as possible and work as we are intended to.
On Tue, Dec 24, 2019, 09:48 Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > This makes sense giving the circumstances. It will get us going. > We can still help reviewing PRs. > > On Tue, Dec 24, 2019, 08:03 Disruptive Solutions < > disruptivesolution...@gmail.com> wrote: > > > A platform like this could help? Samsung seems to use it? Does Apache has > > something like this “Helix Core” and “Swarm” ?? > > > > https://www.perforce.com/products/helix-swarm > > > > Benefit drom these ideas? And you could start with 1 commiter and scale > up > > later. The way of working will be getting more clear and get to the > > “standards” Greg sees?? > > > > > > Verstuurd vanaf mijn iPhone > > > > > Op 24 dec. 2019 om 06:07 heeft Nathan Hartman < > hartman.nat...@gmail.com> > > het volgende geschreven: > > > > > > On Mon, Dec 23, 2019 at 7:51 PM 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. > > > > > > I agree with this because it is premature to change the way we work > > > before there is a documented workflow that helps us understand what to > > > do. > > > > > > Over the next two weeks, we should focus on designing the top-down > > > workflow. It doesn't have to be final and it doesn't have to be > > > perfect. We can improve it over time. But right now it's not ready, > > > so I appreciate Greg's offer to do that, while the workflow is > prepared. > > > > > > Thanks to Greg and everyone, > > > Nathan > > >
