+1 -----Original Message----- From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com] Sent: Monday, December 23, 2019 11:48 PM To: dev@nuttx.apache.org Subject: Re: Single Committer
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 >
