> I see your point, however I do not think the overwhelming feeling is real enough for the folks the contributed to the document.
Now that we really see a how small (and painful submitting) the patch to PR ratio can we not focus on the past not "best practices" and document a real work flow? Here is what that 10,404 word document can look like in 490 words. https://dev.px4.io/master/en/contribute/git_examples.html#git-examples I do not own it, I use it, it works, it informs the developer of what is happening not hundreds of useless emails saying merged prxyz! We need to think Team. We need to value the team's time. None of what we have done foster communication or provide useful information. There are just thousands of emails on a really small project. Can you imagine your inbox with 1000 devs working on this? We have some air time on in the Apache world. It is time to renovate! David -----Original Message----- From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com] Sent: Friday, March 06, 2020 3:30 AM To: dev@nuttx.apache.org Subject: Re: squashing commits or not > Thank you. The link did not lad me and I have no idea what to look at > there > among the 10,404 words... I see your point, however, the steps (and git commands) are all in one place with the necessary explanations. If one decides not to read anything but the commands, they are highlighted with code blocks. > That has never been thoroughly approved and is not the accepted workflow > at present. Yes, but eventually, that's the workflow we are going to call a vote on. All committers can edit and improve it. Non committers can ask to have the necessary permissions. On Thu, Mar 5, 2020 at 5:55 PM David Sidrane <david.sidr...@nscdg.com> wrote: > > Abdelatif, > > Thank you. The link did not lad me and I have no idea what to look at > there > among the 10,404 words... > > David > > -----Original Message----- > From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com] > Sent: Thursday, March 05, 2020 10:41 AM > To: dev@nuttx.apache.org > Subject: Re: squashing commits or not > > > How about clear to the point work steps? Do we have the interim workflow > > listed anywhere that it can be read, without the diatribes? > > I just wrote something really quickly. Maybe you want to take a look [1] > We can add to that section more information on how to squash WIP > commits using interactive rebasing. > I'll come back later to do more. But I need to go. Feel free to edit. > > 1. > https://cwiki.apache.org/confluence/display/NUTTX/Code+Contribution+Workflow+--+Brennan+Ashton#CodeContributionWorkflow--BrennanAshton-BeforeSubmittingYourChanges > > > On Thu, Mar 5, 2020 at 5:37 PM David Sidrane <david.sidr...@nscdg.com> > wrote: > > > > I think you are over-reading this. If we do not have a clear list of > > instructions we are not helping, we are confusing our would be > > committers > > (Additional Committers email). If you do not think of them as Rules but > > more > > of sharing your "best engineering judgment" to educate the group, you > > know, > > Share the knowledge help the community, help the project.... > > > > -----Original Message----- > > From: Gregory Nutt [mailto:spudan...@gmail.com] > > Sent: Thursday, March 05, 2020 9:25 AM > > To: dev@nuttx.apache.org > > Subject: Re: squashing commits or not > > > > No one gets to set any rules. No one gets to enforce any rules. > > Committers are free to do what they choose. That is the Apache way: It > > is anarchy held together by a belief in common principles and a project > > culture. If you can't trust people to do that job, you are working on > > the wrong project. > > > > I will no be held by any such rules. I will always use my best > > engineering judgement. And I will take my scolding when I deserve it. > > > > What you can do, is help to educate people about the pros and cons of > > the work in general. You have to trust that it is everyone's intention > > in their heart to do the best job that they can. But you will never be > > able to force rules to control others behavior in this environment. No > > one has the authority to do that.
