>I do not know what is the problem for receiving patch from email. Obviously most people will just use git and GitHub but providing another way is also fine?
It is not have a problem with the project taking patches. It is just not the ONLY option. > I do not fully get what is the point of your story as I'm not good at reading English stories but if you mean that people should move on to new things, think of Amish. Amish ROFLMAO[1] I am sorry if it does not read well. But I think you got it! Let's embrace it, but not force it. [1] https://en.wikipedia.org/wiki/ROFLMAO -----Original Message----- From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com] Sent: Friday, December 27, 2019 6:16 AM To: dev@nuttx.apache.org Subject: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer) I do not know what is the problem for receiving patch from email. Obviously most people will just use git and GitHub but providing another way is also fine? I do not fully get what is the point of your story as I'm not good at reading English stories but if you mean that people should move on to new things, think of Amish. Thanks. David Sidrane <david.sidr...@nscdg.com> 于2019年12月27日周五 下午9:26写道： > 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? > > From 2d7920055f96f5734d5166e2c58daa16c6dff2f5 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Beat=20K=C3=BCng?= <beat-ku...@gmx.net> > Date: Thu, 28 Nov 2019 13:08:28 +0100 > Subject: [PATCH 01/19] [BACKPORT] fix stm32h7x3xx_dmamux.h: add missing > underscore to defines > > --- > .../src/stm32h7/hardware/stm32h7x3xx_dmamux.h | 140 +++++++++--------- > 1 file changed, 70 insertions(+), 70 deletions(-) > > diff --git a/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h > b/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h > index 7c1f575a86..6c94addc31 100644 > --- a/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h > +++ b/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h > @@ -276,50 +276,50 @@ > .... > > PRs add rich content and context (what branch this applies to at a > minimum)- > that is why they are today's "best practices" > > I would ask all of us to think about new tools[1] and not be doing things > just because[2] > > [1] https://quoteinvestigator.com/2014/05/08/hammer-nail/ > [2] > > https://lists.apache.org/thread.html/98ddb6fcf5a744f3b65f81d850cb535764f16fa207fd883c557fbf4f%40%3Cdev.nuttx.apache.org%3E > > David > > > > -----Original Message----- > From: Nathan Hartman [mailto:hartman.nat...@gmail.com] > Sent: Thursday, December 26, 2019 7:34 PM > To: dev@nuttx.apache.org > Subject: Re: Software release life cycle choices could have implications > on > workflow (was RE: Single Committer) > > On Thu, Dec 26, 2019 at 7:31 PM 张铎(Duo Zhang) <palomino...@gmail.com> > wrote: > > > Yes, feature branch is another story, but I still need to say that, we > > should not just exclude normal contributors. They do not have the > > permission to push to a feature branch either... > > > There is no problem here. Anyone can clone the repo, work on the feature > branch, and submit PR or patch for the upstream feature branch. >
