On Fri, Dec 27, 2019 at 8:26 AM David Sidrane <david.sidr...@nscdg.com> wrote:
> Nathan, > > I am not sure if this is a terminology issue or just being new to github. > (I > feel you. We have all been there!) > > Where do they submit the PR from? > > > https://stackoverflow.com/questions/14906187/how-to-submit-a-pull-request-from-a-cloned-repo > > The only other option is to email patches. > > I do not have any expertise with patches in git other than I can run ' git > format-patch <my branch point>' > > Can anyone tell me what repo, what branch the following is to/from and > where > it should be applied to? > > (snip) > > PRs add rich content and context (what branch this applies to at a > minimum)- > that is why they are today's "best practices" GitHub is great, but as Justin points out some people cannot use it, and as Greg points out, we need to be considerate of ALL users, it's in the INVIOLABLES. So we must support non-GitHub-based contributions regardless of what we do internally within the project. In addition to 'git format-patch' there is also 'git request-pull'. All we need to do in our Workflow is to document exactly how a contributor gets changes to us, and we have to provide 3 options: Option 1: A GitHub pull request Option 2: Email a pull request to dev@ using git request-pull (and we have to document exactly what sequence of git incantations to use) Option 3: For those who do not use git or have git at all, how to get changes based on a release to us. Greg can hopefully enlighten us as to how those customers are currently doing that (are they just zipping their entire nuttx tree and sending it? are they using some other patch-generating program? what?). Once we know, we document exactly what to do. When any of those things reach us (by PR or email) we, the committers, do whatever is necessary to process them through accept&merge, rework, or reject. And again, we have to document for ourselves, the committers, exactly how to do that, including git incantations. This is necessary to ensure that current committers know what to do and also to lower barriers to entry for new committers in the future. The more committers we have and the easier we make it for committers to succeed, the stronger the project will be and the more its longevity is ensured. Nathan
