How to change git description?

[Xiang Xiao]

https://git-wip-us.apache.org/repos/asf?p=incubator-nuttx.git
It's better to change the description from "Apache nuttx" to "Apache NuttX"
https://git-wip-us.apache.org/repos/asf?p=incubator-nuttx-apps.git
It's better to change the description from "Apache nuttx" to "Apache
NuttX Apps"?
The github mirror need to update too, but I can't find the editor
button in both pages.

Thanks
Xiang

404 on site (Project status Nuttx)

[disruptivesolutionsnl]

 

http://incubator.apache.org/projects/nuttx.html

 

Gives back 404's when clicking on links like Board Reports and Website.

 

And Wiki is nog active yet?

 

No dates are filled here? Is this not the right project overview site?
Roadmap/status?

 

Ben

 

Re: How to change git description?

[Duo Zhang]

File an infra issue?

And git-wip-us has been deprecated, now we use gitbox.

https://gitbox.apache.org/repos/asf/incubator-nuttx

https://gitbox.apache.org/repos/asf/incubator-nuttx-apps



Xiang Xiao  于2019年12月27日周五 下午4:59写道：

> https://git-wip-us.apache.org/repos/asf?p=incubator-nuttx.git
> It's better to change the description from "Apache nuttx" to "Apache NuttX"
> https://git-wip-us.apache.org/repos/asf?p=incubator-nuttx-apps.git
> It's better to change the description from "Apache nuttx" to "Apache
> NuttX Apps"?
> The github mirror need to update too, but I can't find the editor
> button in both pages.
>
> Thanks
> Xiang
>

Re: 404 on site (Project status Nuttx)

[Hans]

Hi mentors,

Xiang has already imported the project website Brennan created into the
official Apache NuttX Website repository.

https://github.com/apache/incubator-nuttx-website

How can it be published to https://nuttx.apache.org/?

Thanks,
Huahang




On Fri, Dec 27, 2019 at 5:24 PM  wrote:

>
>
> http://incubator.apache.org/projects/nuttx.html
>
>
>
> Gives back 404's when clicking on links like Board Reports and Website.
>
>
>
> And Wiki is nog active yet?
>
>
>
> No dates are filled here? Is this not the right project overview site?
> Roadmap/status?
>
>
>
> Ben
>
>
>
>

-- 
刘华航 (Hans)
行走, 思考, 在路上

Re: Workflow Development

[Nathan Hartman]

On Fri, Dec 27, 2019 at 12:24 AM Justin Mclean 
wrote:

>
> > A chicken and egg problem: he want to do the contribution become the
> > committer, but the contribution need be done with committer' rights.
>
> No it is not, people can contribute without having a commit bit.


Like I said before, people seem to have trouble wrapping their mind around
that.

Somehow we have to take people by the hand and show them how a
non-committer contributes.

Nathan

Re: How to change git description?

[Xiang Xiao]

Here is JIRA:
https://issues.apache.org/jira/browse/INFRA-19633

On Fri, Dec 27, 2019 at 5:49 PM 张铎(Duo Zhang)  wrote:
>
> File an infra issue?
>
> And git-wip-us has been deprecated, now we use gitbox.
>
> https://gitbox.apache.org/repos/asf/incubator-nuttx
>
> https://gitbox.apache.org/repos/asf/incubator-nuttx-apps
>
>
>
> Xiang Xiao  于2019年12月27日周五 下午4:59写道：
>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-nuttx.git
> > It's better to change the description from "Apache nuttx" to "Apache NuttX"
> > https://git-wip-us.apache.org/repos/asf?p=incubator-nuttx-apps.git
> > It's better to change the description from "Apache nuttx" to "Apache
> > NuttX Apps"?
> > The github mirror need to update too, but I can't find the editor
> > button in both pages.
> >
> > Thanks
> > Xiang
> >

[GitHub] [incubator-nuttx-website] davids5 opened a new pull request #1: Fixed errant ']' README.MD

[GitBox]

davids5 opened a new pull request #1: Fixed errant ']' README.MD
URL: https://github.com/apache/incubator-nuttx-website/pull/1
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: 404 on site (Project status Nuttx)

[spudaneco]

How does this effect ongoing Confuence development on Brennan's old site?  This 
needs to move to a new URL. What is the URL? Will additional changes to 
Brennan's site be lost?Thanks,GregSent from Samsung tablet.
 Original message From: Hans  Date: 
12/27/19  4:16 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: 404 on 
site (Project status Nuttx) Hi mentors,Xiang has already imported the project 
website Brennan created into theofficial Apache NuttX Website 
repository.https://github.com/apache/incubator-nuttx-websiteHow can it be 
published to https://nuttx.apache.org/?Thanks,Huahang-- 刘华航 (Hans)行走, 思考, 在路上

Re: 404 on site (Project status Nuttx)

[Xiang Xiao]

No, this git just has the website content.
The git contain both Brennan and Hans change even Justin, you can see
the full commit here:
https://github.com/apache/incubator-nuttx-website/commits/master
https://nuttx.apache.org should host the content generated from this
git which has a link to wiki

On Fri, Dec 27, 2019 at 7:50 PM spudaneco  wrote:
>
> How does this effect ongoing Confuence development on Brennan's old site?  
> This needs to move to a new URL. What is the URL? Will additional changes to 
> Brennan's site be lost?Thanks,GregSent from Samsung tablet.
>  Original message From: Hans  Date: 
> 12/27/19  4:16 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: 404 on 
> site (Project status Nuttx) Hi mentors,Xiang has already imported the project 
> website Brennan created into theofficial Apache NuttX Website 
> repository.https://github.com/apache/incubator-nuttx-websiteHow can it be 
> published to https://nuttx.apache.org/?Thanks,Huahang-- 刘华航 (Hans)行走, 思考, 在路上

Re: 404 on site (Project status Nuttx)

[Xiang Xiao]

You.can try the generated pages here:
https://apache-nuttx-website.github.io/

On Friday, December 27, 2019, Xiang Xiao  wrote:

> No, this git just has the website content.
> The git contain both Brennan and Hans change even Justin, you can see
> the full commit here:
> https://github.com/apache/incubator-nuttx-website/commits/master
> https://nuttx.apache.org should host the content generated from this
> git which has a link to wiki
>
> On Fri, Dec 27, 2019 at 7:50 PM spudaneco  wrote:
> >
> > How does this effect ongoing Confuence development on Brennan's old
> site?  This needs to move to a new URL. What is the URL? Will additional
> changes to Brennan's site be lost?Thanks,GregSent from Samsung tablet.
> >  Original message From: Hans 
> Date: 12/27/19  4:16 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject:
> Re: 404 on site (Project status Nuttx) Hi mentors,Xiang has already
> imported the project website Brennan created into theofficial Apache NuttX
> Website repository.https://github.com/apache/incubator-nuttx-websiteHow
> can it be published to https://nuttx.apache.org/?Thanks,Huahang-- 刘华航
> (Hans)行走, 思考, 在路上
>

RE: 404 on site (Project status Nuttx)

[David Sidrane]

What is in the way of fixing the 404?



-Original Message-
From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
Sent: Friday, December 27, 2019 3:59 AM
To: dev@nuttx.apache.org
Subject: Re: 404 on site (Project status Nuttx)

No, this git just has the website content.
The git contain both Brennan and Hans change even Justin, you can see
the full commit here:
https://github.com/apache/incubator-nuttx-website/commits/master
https://nuttx.apache.org should host the content generated from this
git which has a link to wiki

On Fri, Dec 27, 2019 at 7:50 PM spudaneco  wrote:
>
> How does this effect ongoing Confuence development on Brennan's old site?
> This needs to move to a new URL. What is the URL? Will additional changes
> to Brennan's site be lost?Thanks,GregSent from Samsung tablet.
>  Original message From: Hans  Date:
> 12/27/19  4:16 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: 404
> on site (Project status Nuttx) Hi mentors,Xiang has already imported the
> project website Brennan created into theofficial Apache NuttX Website
> repository.https://github.com/apache/incubator-nuttx-websiteHow can it be
> published to https://nuttx.apache.org/?Thanks,Huahang-- 刘华航 (Hans)行走, 思考,
> 在路上

RE: 404 on site (Project status Nuttx)

[David Sidrane]

The [GitHub] tab lands on one repo.
Do you need a landing page or repo? That lists all the other repos?

-Original Message-
From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
Sent: Friday, December 27, 2019 4:03 AM
To: dev@nuttx.apache.org
Subject: Re: 404 on site (Project status Nuttx)

You.can try the generated pages here:
https://apache-nuttx-website.github.io/

On Friday, December 27, 2019, Xiang Xiao  wrote:

> No, this git just has the website content.
> The git contain both Brennan and Hans change even Justin, you can see
> the full commit here:
> https://github.com/apache/incubator-nuttx-website/commits/master
> https://nuttx.apache.org should host the content generated from this
> git which has a link to wiki
>
> On Fri, Dec 27, 2019 at 7:50 PM spudaneco  wrote:
> >
> > How does this effect ongoing Confuence development on Brennan's old
> site?  This needs to move to a new URL. What is the URL? Will additional
> changes to Brennan's site be lost?Thanks,GregSent from Samsung tablet.
> >  Original message From: Hans 
> Date: 12/27/19  4:16 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject:
> Re: 404 on site (Project status Nuttx) Hi mentors,Xiang has already
> imported the project website Brennan created into theofficial Apache NuttX
> Website repository.https://github.com/apache/incubator-nuttx-websiteHow
> can it be published to https://nuttx.apache.org/?Thanks,Huahang-- 刘华航
> (Hans)行走, 思考, 在路上
>

Re: 404 on site (Project status Nuttx)

[Xiang Xiao]

I open a JIRA to get INFRA help:
https://issues.apache.org/jira/plugins/servlet/mobile#issue/INFRA-19634


On Friday, December 27, 2019, David Sidrane  wrote:

> What is in the way of fixing the 404?
>
>
>
> -Original Message-
> From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
> Sent: Friday, December 27, 2019 3:59 AM
> To: dev@nuttx.apache.org
> Subject: Re: 404 on site (Project status Nuttx)
>
> No, this git just has the website content.
> The git contain both Brennan and Hans change even Justin, you can see
> the full commit here:
> https://github.com/apache/incubator-nuttx-website/commits/master
> https://nuttx.apache.org should host the content generated from this
> git which has a link to wiki
>
> On Fri, Dec 27, 2019 at 7:50 PM spudaneco  wrote:
> >
> > How does this effect ongoing Confuence development on Brennan's old site?
> > This needs to move to a new URL. What is the URL? Will additional changes
> > to Brennan's site be lost?Thanks,GregSent from Samsung tablet.
> >  Original message From: Hans  Date:
> > 12/27/19  4:16 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: 404
> > on site (Project status Nuttx) Hi mentors,Xiang has already imported the
> > project website Brennan created into theofficial Apache NuttX Website
> > repository.https://github.com/apache/incubator-nuttx-websiteHow can it
> be
> > published to https://nuttx.apache.org/?Thanks,Huahang-- 刘华航 (Hans)行走,
> 思考,
> > 在路上
>

RE: 404 on site (Project status Nuttx)

[David Sidrane]

Did you see the PR for the README.md There was a typo in the MD. But the
Link looks wrong to me and I would not know where to point it at this point.

-Original Message-
From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
Sent: Friday, December 27, 2019 4:10 AM
To: dev@nuttx.apache.org
Subject: Re: 404 on site (Project status Nuttx)

I open a JIRA to get INFRA help:
https://issues.apache.org/jira/plugins/servlet/mobile#issue/INFRA-19634


On Friday, December 27, 2019, David Sidrane  wrote:

> What is in the way of fixing the 404?
>
>
>
> -Original Message-
> From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
> Sent: Friday, December 27, 2019 3:59 AM
> To: dev@nuttx.apache.org
> Subject: Re: 404 on site (Project status Nuttx)
>
> No, this git just has the website content.
> The git contain both Brennan and Hans change even Justin, you can see
> the full commit here:
> https://github.com/apache/incubator-nuttx-website/commits/master
> https://nuttx.apache.org should host the content generated from this
> git which has a link to wiki
>
> On Fri, Dec 27, 2019 at 7:50 PM spudaneco  wrote:
> >
> > How does this effect ongoing Confuence development on Brennan's old
> > site?
> > This needs to move to a new URL. What is the URL? Will additional
> > changes
> > to Brennan's site be lost?Thanks,GregSent from Samsung tablet.
> >  Original message From: Hans  Date:
> > 12/27/19  4:16 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: 404
> > on site (Project status Nuttx) Hi mentors,Xiang has already imported the
> > project website Brennan created into theofficial Apache NuttX Website
> > repository.https://github.com/apache/incubator-nuttx-websiteHow can it
> be
> > published to https://nuttx.apache.org/?Thanks,Huahang-- 刘华航 (Hans)行走,
> 思考,
> > 在路上
>

[GitHub] [incubator-nuttx-website] huahang opened a new pull request #2: fix apache git repo links

[GitBox]

huahang opened a new pull request #2: fix apache git repo links
URL: https://github.com/apache/incubator-nuttx-website/pull/2
 
 
   Signed-off-by: hans 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx-website] huahang commented on issue #1: Fixed errant ']' README.MD

[GitBox]

huahang commented on issue #1: Fixed errant ']' README.MD
URL: 
https://github.com/apache/incubator-nuttx-website/pull/1#issuecomment-569262429
 
 
   LGTM


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: How to change git description?

[Xiang Xiao]

On Fri, Dec 27, 2019 at 5:49 PM 张铎(Duo Zhang)  wrote:
>
> File an infra issue?
>
> And git-wip-us has been deprecated, now we use gitbox.
>
> https://gitbox.apache.org/repos/asf/incubator-nuttx
>
> https://gitbox.apache.org/repos/asf/incubator-nuttx-apps
>

Hans send a patch fix it, please take a look:
https://github.com/apache/incubator-nuttx-website/pull/2

>
>
> Xiang Xiao  于2019年12月27日周五 下午4:59写道：
>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-nuttx.git
> > It's better to change the description from "Apache nuttx" to "Apache NuttX"
> > https://git-wip-us.apache.org/repos/asf?p=incubator-nuttx-apps.git
> > It's better to change the description from "Apache nuttx" to "Apache
> > NuttX Apps"?
> > The github mirror need to update too, but I can't find the editor
> > button in both pages.
> >
> > Thanks
> > Xiang
> >

Are you familiar with the HAM story? (Was Are you failure with the HAM Story?)

[David Sidrane]

If I could only spell and see my errors. dyslexics untie[1]

1 http://www.specialcompass.ca/shakiras-blog/2017/10/23/dyslexic-untie

On 2019/12/20 21:09:17, David Sidrane  wrote: 
> All,
> 
> This is one of my favorite Lessons that I learned... reposted from Private
> 
> Are you failure with the HAM Story?
> 
> A husband and his wife were in their kitchen. The husband was sitting at the
> kitchen table reading the newspaper while his wife was preparing a ham for
> dinner. The husband watched the wife cut off about one inch from either end
> of the ham. He asked why she cut the end off, proclaiming “that’s a waste of
> good ham!” She said “that’s the way my mom prepared the ham.” The husband
> asked “why did your mom cut the ends off?” The wife didn’t know.
> 
> Later, the wife called her mom to find out why she cut the ends of the ham
> off. Her mom said “because that was the way my mom prepared ham.”
> 
> The wife’s grandma passed away several years earlier, but her Grandpa was
> still living. She called her Grandpa and asked “Grandpa, why did Grandma cut
> the ends off of the ham?” He was silent as he thought for a moment. Then he
> replied, “so the ham could fit in the baking pan.”
> 
> It relates nicely to https://en.wikipedia.org/wiki/Cargo_cult_programming
> 
> David
> 
> 
> -Original Message-
> From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
> Sent: Friday, December 20, 2019 11:26 AM
> To: priv...@nuttx.apache.org
> Subject: Re: Email Attachments (Was Re: Masayuki Ishikawa added to NuttX
> committers)
> 
> On Fri, Dec 20, 2019 at 12:31 PM Alan Carvalho de Assis
>  wrote:
> > What is the issue with .patch extension? This is default name
> > generated by "git format-patch" command. Could you please explain the
> > reason?
> 
> I don't know if there is an issue. I only mentioned it because I was
> once told it makes it easier to review patches in some email clients:
> 
> On Wed Jul 31 11:11:11 CDT 2019 Daniel Shahaf wrote:
> > By the way, in the future could you please name patches with a *.txt
> > extension?  That should cause them to have a text/* MIME type which, in
> > some email clients, makes the attachments easier to review.
> 
> Full message:
> https://mailman.red-bean.com/pipermail/svnbook-dev/2019-July/017433.html
> 
> Nathan
> 

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane]

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 '

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?= 
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)  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.

Re: 404 on site (Project status Nuttx)

[Gregory Nutt]

You.can try the generated pages here:
https://apache-nuttx-website.github.io/

How would you navigate to the Confluence Wiki from these pages? Or am I 
just confused?


The Confluence database is separate, correct?  If we were to make 
Confluence changes under this temporary URL, would they be permanent?  
Or do we have to wait for the pages to be moved to their final location?


Greg

RE: 404 on site (Project status Nuttx)

[David Sidrane]

> Confused

Yes - I was too - this is the website not wiki.

Look here https://whimsy.apache.org/roster/ppmc/nuttx under Naming that is
the 404

This is the link that works https://apache-nuttx-website.github.io/


> The Confluence database is separate, correct?  If we were to make
Yes.

> Confluence changes under this temporary URL, would they be permanent?

This needs fixing. I would do it but Infra tickets are not sorted by "Nuttx"
so I have no idea if it has been requested.

> Or do we have to wait for the pages to be moved to their final location?

That was not clear to me either - but it you read the page[1]

I think the plan is to land on the website and refer to the wiki  so +1 for
me

[1] https://apache-nuttx-website.github.io/

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Friday, December 27, 2019 5:27 AM
To: dev@nuttx.apache.org
Subject: Re: 404 on site (Project status Nuttx)


> You.can try the generated pages here:
> https://apache-nuttx-website.github.io/
>
How would you navigate to the Confluence Wiki from these pages? Or am I
just confused?

The Confluence database is separate, correct?  If we were to make
Confluence changes under this temporary URL, would they be permanent?
Or do we have to wait for the pages to be moved to their final location?

Greg

RE: 404 on site (Project status Nuttx)

[David Sidrane]

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Friday, December 27, 2019 5:27 AM
To: dev@nuttx.apache.org
Subject: Re: 404 on site (Project status Nuttx)





> You.can try the generated pages here:

> https://apache-nuttx-website.github.io/

>

How would you navigate to the Confluence Wiki from these pages? Or am I

just confused?



The Confluence database is separate, correct?  If we were to make

Confluence changes under this temporary URL, would they be permanent?

Or do we have to wait for the pages to be moved to their final location?



Greg

Re: 404 on site (Project status Nuttx)

[Xiang Xiao]

On Fri, Dec 27, 2019 at 9:27 PM Gregory Nutt  wrote:

>
> > You.can try the generated pages here:
> > https://apache-nuttx-website.github.io/
> >
> How would you navigate to the Confluence Wiki from these pages? Or am I
> just confused?
>
>
 At the middle of https://apache-nuttx-website.github.io:

[image: capture.JPG]


> The Confluence database is separate, correct?  If we were to make
> Confluence changes under this temporary URL, would they be permanent?
> Or do we have to wait for the pages to be moved to their final location?
>

Yes, website is separated from wiki. The Confluence still host in the
original location, no change.
Website point to the test location now:
https://cwiki.apache.org/confluence/display/NUTTXTEST/Nuttx
We can update the website point to the official location once wiki move to
that.


>
> Greg
>
>

Re: Apache NuttX website

[Xiang Xiao]

Brennan, could you associate your apache and github account here?
https://whimsy.apache.org/roster/committer/btashton
And enable 2FA here:
https://gitbox.apache.org/setup/
So you can review the future website related patch.
The web technology is far beyond my knowledge, I can't do the depth
review except the typo error.

Thanks
Xiang

On Sat, Dec 21, 2019 at 12:54 PM Brennan Ashton
 wrote:
>
> Could we create the repo for the website.
> http://www.apache.org/dev/project-site.html
>
> The one I created is based off the Jekyll template as discussed here.
> https://incubator.apache.org/guides/sites.html#publishing_your_website

[GitHub] [incubator-nuttx-website] xiaoxiang781216 merged pull request #2: fix apache git repo links

[GitBox]

xiaoxiang781216 merged pull request #2: fix apache git repo links
URL: https://github.com/apache/incubator-nuttx-website/pull/2
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx-website] xiaoxiang781216 merged pull request #1: Fixed errant ']' README.MD

[GitBox]

xiaoxiang781216 merged pull request #1: Fixed errant ']' README.MD
URL: https://github.com/apache/incubator-nuttx-website/pull/1
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx-website] davids5 opened a new pull request #3: Still Wrong

[GitBox]

davids5 opened a new pull request #3: Still Wrong
URL: https://github.com/apache/incubator-nuttx-website/pull/3
 
 
   Same issue leading [


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Nathan Hartman]

On Fri, Dec 27, 2019 at 8:26 AM David Sidrane 
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 '
>
> 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

[GitHub] [incubator-nuttx-website] davids5 merged pull request #3: Still Wrong

[GitBox]

davids5 merged pull request #3: Still Wrong
URL: https://github.com/apache/incubator-nuttx-website/pull/3
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Duo Zhang]

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  于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 '
>
> 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?= 
> 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) 
> 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.
>

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane]

+1 I agree with all that you have said.

I would just add the WHY.  Let's not teach bad habits (HAM Story)

Yes document them all and describe why fall a back may be needed.

We might even want to rate them as preferred and acceptable (Just like the
NuttX Coding Standard document does)

David

-Original Message-
From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
Sent: Friday, December 27, 2019 6:01 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)

On Fri, Dec 27, 2019 at 8:26 AM David Sidrane 
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 '
>
> 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

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Gregory Nutt]

Hi, Nathan,

I remember promising to help you with the workflow document a few days 
ago.  I am having a little trouble following your outline.  Fleshing it 
out a little more would probably be helpful to keep us on track.


Anyway... I did make some first small changes today and I am addressing 
this particular topic.  Please review.



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.


I have accepted changes in most any form that people want to send them 
to me.  But never while zipped trees.  I have no idea what I would do 
with that.   For small changes, it is the content that matters, not so 
much the form.  I have accepted emails just indicating in discussion one 
or two line changes.  I don't like those very much but I have accepted them.


Form does matter for larger changes.  Some people send diffs generated 
with the Linux command line 'diff -r ' command.  Those work fine.  GIT 
patches work too.  No one has sent a 'git request-pull' but I suppose 
you will deal with that as with a patch.  Basically diffs, patches, and 
textual pull requests are all the same thing just with varying amounts 
of metadata.


For me, PRs were less used.  I would get 20 patches per each PR. I did 
not like to accept PRs in the old Bitbucket repositories because they 
went directly to master which is not a good practice.  I did not have a 
development branch and I don't know if Bitbucket supported changing the 
base of a PR like github does. But PRs were a nightmare in that 
environment.  I think they will work better for us because we have more 
process in place to deal with them.


When you are set up to handle PRs they are sweet.


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.


I think most of us are getting on the same page.  DavidS is still the 
outlier.  David has a lot of knowledge, it would be good if we could get 
him on board with the rest of us.  We could do so much better if we 
worked together.


Greg

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane]

>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  于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 '
>
> 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?= 
> 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) 
> 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.
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Nathan Hartman]

On Fri, Dec 27, 2019 at 9:26 AM Gregory Nutt  wrote:

> Hi, Nathan,
>
> I remember promising to help you with the workflow document a few days
> ago.  I am having a little trouble following your outline.  Fleshing it
> out a little more would probably be helpful to keep us on track.
>
> Anyway... I did make some first small changes today and I am addressing
> this particular topic.  Please review.


I just saw the changes in the email notification. Thanks so much for
helping with that!! It looks good and I will review more carefully soon.
Also I'll flesh out the outline more. Unfortunately it might take me until
Sunday to do it, but I'll work on it as soon as I can.

Thanks again for your help!

Nathan

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane]

Hi Greg,

I have used Bit bucket and Github and others SCM. I have had more positive
Github experiences

For me Github has always been a better tool except for the killer feature on
BB of meld like diff.

I am not working against anyone. I am trying to share what I know about GH,
the mistakes I have made with it and do not want to repeat.

I do not want to limit anyone's ability to do their work their way [GREEN
and CLEAN]

Can we all agree: That we do not want a github NOOB  to define a github work
flow?
Can we all agree: That we do not want a patch NOOB  to define a patch work
flow?


> I don't know if Bitbucket supported changing the base of a PR like github
> does. But PRs were a nightmare in that
> environment.  I think they will work better for us because we have more
> process in place to deal with them.

>When you are set up to handle PRs they are sweet.

If we are using github, yes they are. The argument about pr braches in the
repo is pointless.

Look at the website repos. Look what github does for a committer vs a
contributor.

Committer - 2 options commit to master or branch in it the repo
Contributor - fork is created.

When I (as a committer) did a PR via the web UI - which is 100% appropriate
for what it was doing.

Notice what happened in the repo.

See https://github.com/apache/incubator-nuttx-website/branches

Now do you see why the argument makes sense?

Are we going to prohibit this? Think about the ramification. We as
committers will not be able to use the UI when it makes sense.

David

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Friday, December 27, 2019 6:27 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)

Hi, Nathan,

I remember promising to help you with the workflow document a few days
ago.  I am having a little trouble following your outline.  Fleshing it
out a little more would probably be helpful to keep us on track.

Anyway... I did make some first small changes today and I am addressing
this particular topic.  Please review.

> 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.

I have accepted changes in most any form that people want to send them
to me.  But never while zipped trees.  I have no idea what I would do
with that.   For small changes, it is the content that matters, not so
much the form.  I have accepted emails just indicating in discussion one
or two line changes.  I don't like those very much but I have accepted them.

Form does matter for larger changes.  Some people send diffs generated
with the Linux command line 'diff -r ' command.  Those work fine.  GIT
patches work too.  No one has sent a 'git request-pull' but I suppose
you will deal with that as with a patch.  Basically diffs, patches, and
textual pull requests are all the same thing just with varying amounts
of metadata.

For me, PRs were less used.  I would get 20 patches per each PR. I did
not like to accept PRs in the old Bitbucket repositories because they
went directly to master which is not a good practice.  I did not have a
development branch and I don't know if Bitbucket supported changing the
base of a PR like github does. But PRs were a nightmare in that
environment.  I think they will work better for us because we have more
process in place to deal with them.

When you are set up to handle PRs they are sweet.

> 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.

I think most of us are getting on the same page.  DavidS is still the
outlier.  David has a lot of knowledge, it would be good if we could get
him on board with the rest of us.  We could do so much better if we
worked together.

Greg

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Duo Zhang]

Again, think of you are a contributor, not a commiter. Not all contributors
are committers, you should not use a different (official) workflow
comparing to them. That's my point.

David Sidrane  于2019年12月27日周五 下午10:59写道：

> Hi Greg,
>
> I have used Bit bucket and Github and others SCM. I have had more positive
> Github experiences
>
> For me Github has always been a better tool except for the killer feature
> on
> BB of meld like diff.
>
> I am not working against anyone. I am trying to share what I know about GH,
> the mistakes I have made with it and do not want to repeat.
>
> I do not want to limit anyone's ability to do their work their way [GREEN
> and CLEAN]
>
> Can we all agree: That we do not want a github NOOB  to define a github
> work
> flow?
> Can we all agree: That we do not want a patch NOOB  to define a patch work
> flow?
>
>
> > I don't know if Bitbucket supported changing the base of a PR like github
> > does. But PRs were a nightmare in that
> > environment.  I think they will work better for us because we have more
> > process in place to deal with them.
>
> >When you are set up to handle PRs they are sweet.
>
> If we are using github, yes they are. The argument about pr braches in the
> repo is pointless.
>
> Look at the website repos. Look what github does for a committer vs a
> contributor.
>
> Committer - 2 options commit to master or branch in it the repo
> Contributor - fork is created.
>
> When I (as a committer) did a PR via the web UI - which is 100% appropriate
> for what it was doing.
>
> Notice what happened in the repo.
>
> See https://github.com/apache/incubator-nuttx-website/branches
>
> Now do you see why the argument makes sense?
>
> Are we going to prohibit this? Think about the ramification. We as
> committers will not be able to use the UI when it makes sense.
>
> David
>
> -Original Message-
> From: Gregory Nutt [mailto:spudan...@gmail.com]
> Sent: Friday, December 27, 2019 6:27 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (was RE: Single Committer)
>
> Hi, Nathan,
>
> I remember promising to help you with the workflow document a few days
> ago.  I am having a little trouble following your outline.  Fleshing it
> out a little more would probably be helpful to keep us on track.
>
> Anyway... I did make some first small changes today and I am addressing
> this particular topic.  Please review.
>
> > 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.
>
> I have accepted changes in most any form that people want to send them
> to me.  But never while zipped trees.  I have no idea what I would do
> with that.   For small changes, it is the content that matters, not so
> much the form.  I have accepted emails just indicating in discussion one
> or two line changes.  I don't like those very much but I have accepted
> them.
>
> Form does matter for larger changes.  Some people send diffs generated
> with the Linux command line 'diff -r ' command.  Those work fine.  GIT
> patches work too.  No one has sent a 'git request-pull' but I suppose
> you will deal with that as with a patch.  Basically diffs, patches, and
> textual pull requests are all the same thing just with varying amounts
> of metadata.
>
> For me, PRs were less used.  I would get 20 patches per each PR. I did
> not like to accept PRs in the old Bitbucket repositories because they
> went directly to master which is not a good practice.  I did not have a
> development branch and I don't know if Bitbucket supported changing the
> base of a PR like github does. But PRs were a nightmare in that
> environment.  I think they will work better for us because we have more
> process in place to deal with them.
>
> When you are set up to handle PRs they are sweet.
>
> > 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.
>
> I think most of us are getting on the same page.  DavidS is still the
> outlier.  David has a lot of knowledge, it would be good if we could get
> him on board with the rest of us.  We could do so much better if we
> worked together.
>
> Greg
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Gregory Nutt]

Again, think of you are a contributor, not a commiter. Not all contributors
are committers, you should not use a different (official) workflow
comparing to them. That's my point.
Everything falls into place neatly when you consider the workflow from 
the point of view of the NuttX end-user / contributor.

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Alin Jerpelea]

I use GH on all projects that accept it and it is a breeze to work with PR.

I clone the project add my commit and make a PR that can be reviewed and
amended depending on the case.

BB was harder to use and I felt that the edit and review in place were some
of the drawbacks.

I agree that with good documentation the PR flow should be easy to handle
and review.



On Fri, Dec 27, 2019, 16:59 David Sidrane  wrote:

> Hi Greg,
>
> I have used Bit bucket and Github and others SCM. I have had more positive
> Github experiences
>
> For me Github has always been a better tool except for the killer feature
> on
> BB of meld like diff.
>
> I am not working against anyone. I am trying to share what I know about GH,
> the mistakes I have made with it and do not want to repeat.
>
> I do not want to limit anyone's ability to do their work their way [GREEN
> and CLEAN]
>
> Can we all agree: That we do not want a github NOOB  to define a github
> work
> flow?
> Can we all agree: That we do not want a patch NOOB  to define a patch work
> flow?
>
>
> > I don't know if Bitbucket supported changing the base of a PR like github
> > does. But PRs were a nightmare in that
> > environment.  I think they will work better for us because we have more
> > process in place to deal with them.
>
> >When you are set up to handle PRs they are sweet.
>
> If we are using github, yes they are. The argument about pr braches in the
> repo is pointless.
>
> Look at the website repos. Look what github does for a committer vs a
> contributor.
>
> Committer - 2 options commit to master or branch in it the repo
> Contributor - fork is created.
>
> When I (as a committer) did a PR via the web UI - which is 100% appropriate
> for what it was doing.
>
> Notice what happened in the repo.
>
> See https://github.com/apache/incubator-nuttx-website/branches
>
> Now do you see why the argument makes sense?
>
> Are we going to prohibit this? Think about the ramification. We as
> committers will not be able to use the UI when it makes sense.
>
> David
>
> -Original Message-
> From: Gregory Nutt [mailto:spudan...@gmail.com]
> Sent: Friday, December 27, 2019 6:27 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (was RE: Single Committer)
>
> Hi, Nathan,
>
> I remember promising to help you with the workflow document a few days
> ago.  I am having a little trouble following your outline.  Fleshing it
> out a little more would probably be helpful to keep us on track.
>
> Anyway... I did make some first small changes today and I am addressing
> this particular topic.  Please review.
>
> > 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.
>
> I have accepted changes in most any form that people want to send them
> to me.  But never while zipped trees.  I have no idea what I would do
> with that.   For small changes, it is the content that matters, not so
> much the form.  I have accepted emails just indicating in discussion one
> or two line changes.  I don't like those very much but I have accepted
> them.
>
> Form does matter for larger changes.  Some people send diffs generated
> with the Linux command line 'diff -r ' command.  Those work fine.  GIT
> patches work too.  No one has sent a 'git request-pull' but I suppose
> you will deal with that as with a patch.  Basically diffs, patches, and
> textual pull requests are all the same thing just with varying amounts
> of metadata.
>
> For me, PRs were less used.  I would get 20 patches per each PR. I did
> not like to accept PRs in the old Bitbucket repositories because they
> went directly to master which is not a good practice.  I did not have a
> development branch and I don't know if Bitbucket supported changing the
> base of a PR like github does. But PRs were a nightmare in that
> environment.  I think they will work better for us because we have more
> process in place to deal with them.
>
> When you are set up to handle PRs they are sweet.
>
> > 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.
>
> I think most of us are getting on the same page.  DavidS is still the
> outlier.  David has a lot of knowledge, it would be good if we could get
> him on board with the rest of us.  We could do so much better if we
> worked together.
>
> G

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Xiang Xiao]

On Fri, Dec 27, 2019 at 10:59 PM David Sidrane  wrote:
>
> Hi Greg,
>
> I have used Bit bucket and Github and others SCM. I have had more positive
> Github experiences
>
> For me Github has always been a better tool except for the killer feature on
> BB of meld like diff.
>
> I am not working against anyone. I am trying to share what I know about GH,
> the mistakes I have made with it and do not want to repeat.
>
> I do not want to limit anyone's ability to do their work their way [GREEN
> and CLEAN]
>
> Can we all agree: That we do not want a github NOOB  to define a github work
> flow?
> Can we all agree: That we do not want a patch NOOB  to define a patch work
> flow?
>
>
> > I don't know if Bitbucket supported changing the base of a PR like github
> > does. But PRs were a nightmare in that
> > environment.  I think they will work better for us because we have more
> > process in place to deal with them.
>
> >When you are set up to handle PRs they are sweet.
>
> If we are using github, yes they are. The argument about pr braches in the
> repo is pointless.
>
> Look at the website repos. Look what github does for a committer vs a
> contributor.
>
> Committer - 2 options commit to master or branch in it the repo

Even committer shouldn't modify anything inside official repo without
the review process.
Committer can merge patch just because the patch pass all workflow criteria.
Committer can create branch just because the workflow allow this for
some special case(to be discussed).
Committer shouldn't abuse his/her power inside official repo just
because he/she like to do so.
Committer just has one option fork, committer's patch need pass
through the same workflow just like the contributor.

> Contributor - fork is created.
>
> When I (as a committer) did a PR via the web UI - which is 100% appropriate
> for what it was doing.
>
> Notice what happened in the repo.

Yes, you manually create a branch in official repo without any review process.

> See https://github.com/apache/incubator-nuttx-website/branches
>
> Now do you see why the argument makes sense?
>

No, since the normal contributor even don't have right to modify
anything in official repo. Only committer can hit this issue, you just
abuse the committer power.
This also demonstrate PX4 workflow encourage people modify the
official repo directly just like local fork, I don't think it's a good
habit.

> Are we going to prohibit this? Think about the ramification. We as
> committers will not be able to use the UI when it makes sense.

Of course, we should prohibit any modification which doesn't pass the
review process like this enter the repo.
You can do anything in your fork with UI, but shouldn't mess up the
official repo.
Many people will sync up with the official repo, any partial or stale
work just make the newbie confusion.

>
> David
>
> -Original Message-
> From: Gregory Nutt [mailto:spudan...@gmail.com]
> Sent: Friday, December 27, 2019 6:27 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (was RE: Single Committer)
>
> Hi, Nathan,
>
> I remember promising to help you with the workflow document a few days
> ago.  I am having a little trouble following your outline.  Fleshing it
> out a little more would probably be helpful to keep us on track.
>
> Anyway... I did make some first small changes today and I am addressing
> this particular topic.  Please review.
>
> > 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.
>
> I have accepted changes in most any form that people want to send them
> to me.  But never while zipped trees.  I have no idea what I would do
> with that.   For small changes, it is the content that matters, not so
> much the form.  I have accepted emails just indicating in discussion one
> or two line changes.  I don't like those very much but I have accepted them.
>
> Form does matter for larger changes.  Some people send diffs generated
> with the Linux command line 'diff -r ' command.  Those work fine.  GIT
> patches work too.  No one has sent a 'git request-pull' but I suppose
> you will deal with that as with a patch.  Basically diffs, patches, and
> textual pull requests are all the same thing just with varying amounts
> of metadata.
>
> For me, PRs were less used.  I would get 20 patches per each PR. I did
> not like to accept PRs in the old Bitbucket repositories because they
> went directly to master which is not a good practice.  I did not have a
> development branch and I don't know if Bitbucket supported changing the
> base of a PR like github does. But PRs were a nightmare in that
> environment.  I think they wi

Re: Apache NuttX website

[Brennan Ashton]

Unfortunately that website requires you to double click to edit fields
(what?) which I cannot do on mobile, so I will have to wait until Saturday
or Sunday to do that You can tag me @btashton for now.

On Fri, Dec 27, 2019, 5:49 AM Xiang Xiao  wrote:

> Brennan, could you associate your apache and github account here?
> https://whimsy.apache.org/roster/committer/btashton
> And enable 2FA here:
> https://gitbox.apache.org/setup/
> So you can review the future website related patch.
> The web technology is far beyond my knowledge, I can't do the depth
> review except the typo error.
>
> Thanks
> Xiang
>
> On Sat, Dec 21, 2019 at 12:54 PM Brennan Ashton
>  wrote:
> >
> > Could we create the repo for the website.
> > http://www.apache.org/dev/project-site.html
> >
> > The one I created is based off the Jekyll template as discussed here.
> > https://incubator.apache.org/guides/sites.html#publishing_your_website
>

Re: Apache NuttX website

[Abdelatif Guettouche]

Did you try this one: https://id.apache.org/

On Fri, Dec 27, 2019 at 4:04 PM Brennan Ashton
 wrote:
>
> Unfortunately that website requires you to double click to edit fields
> (what?) which I cannot do on mobile, so I will have to wait until Saturday
> or Sunday to do that You can tag me @btashton for now.
>
> On Fri, Dec 27, 2019, 5:49 AM Xiang Xiao  wrote:
>
> > Brennan, could you associate your apache and github account here?
> > https://whimsy.apache.org/roster/committer/btashton
> > And enable 2FA here:
> > https://gitbox.apache.org/setup/
> > So you can review the future website related patch.
> > The web technology is far beyond my knowledge, I can't do the depth
> > review except the typo error.
> >
> > Thanks
> > Xiang
> >
> > On Sat, Dec 21, 2019 at 12:54 PM Brennan Ashton
> >  wrote:
> > >
> > > Could we create the repo for the website.
> > > http://www.apache.org/dev/project-site.html
> > >
> > > The one I created is based off the Jekyll template as discussed here.
> > > https://incubator.apache.org/guides/sites.html#publishing_your_website
> >

Re: User Email Account

[Abdelatif Guettouche]

> The dev list traffic may reduce after we finish the workflow discussion.
> but email from GibBox will become more and more, can we send them to
> rev...@nuttx.apache.org to avoid the review message mess up the dev
> list?

While reading some projects' board reports, I came across this:

> Gitbox traffic is now going to issues@. The community was losing dev@
>  subscribers because of the high volume of traffic from Gitbox.

Once we are all set up and ready to receive patches/PRs, we may run
into the same issue.


On Thu, Dec 26, 2019 at 1:34 PM Xiang Xiao  wrote:
>
> The dev list traffic may reduce after we finish the workflow discussion.
> but email from GibBox will become more and more, can we send them to
> rev...@nuttx.apache.org to avoid the review message mess up the dev
> list?
>
> Thanks
> Xiang
>
> On Thu, Dec 26, 2019 at 8:19 PM spudaneco  wrote:
> >
> > I may grumble a bit bur I always follow Justin's advice.I do think that
> > NuttX is diferent from other new podlings because  began with a huge user
> > base and has a few different needs on day 1 as a mature project.I don't
> > believe that finding new committers will be a problem.Sent from Samsung
> > tablet.
> >  Original message From: Adam Feuer  Date:
> > 12/26/19  1:23 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: User
> > Email Account I think what Justin is saying is that it's going to seem like
> > uncomfortablechaos for a bit, but will eventually settle down into a better
> > state.From what I know about well-functioning teams, that seems right.
> > Form,storm, norm,
> > perform.
> > :)cheersadamOn Wed, Dec 25, 2019 at 8:28 PM Justin Mclean
> > wrote:> Hi,>> Most of those are not current
> > incubating projects. Some of them did not> become to level projects. Just
> > about all did not start with user lists.> Creating a seperate user list this
> > early in previous incubating projects> has slowed or hindered their
> > community growth. You want users involved so> that they become committers.
> > At no point have I said you can't do this but> the PPMC needs to carefully
> > consider it. My Internet access is limited> right now but if you search on
> > the incubator general list you'll see> several discussions on this.>>
> > Thanks,> Justin>-- Adam Feuer 

Re: Apache NuttX website

[Brennan Ashton]

That worked perfect.  Xiang you should be able to assign things to me now.

On Fri, Dec 27, 2019, 8:06 AM Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:

> Did you try this one: https://id.apache.org/
>
> On Fri, Dec 27, 2019 at 4:04 PM Brennan Ashton
>  wrote:
> >
> > Unfortunately that website requires you to double click to edit fields
> > (what?) which I cannot do on mobile, so I will have to wait until
> Saturday
> > or Sunday to do that You can tag me @btashton for now.
> >
> > On Fri, Dec 27, 2019, 5:49 AM Xiang Xiao 
> wrote:
> >
> > > Brennan, could you associate your apache and github account here?
> > > https://whimsy.apache.org/roster/committer/btashton
> > > And enable 2FA here:
> > > https://gitbox.apache.org/setup/
> > > So you can review the future website related patch.
> > > The web technology is far beyond my knowledge, I can't do the depth
> > > review except the typo error.
> > >
> > > Thanks
> > > Xiang
> > >
> > > On Sat, Dec 21, 2019 at 12:54 PM Brennan Ashton
> > >  wrote:
> > > >
> > > > Could we create the repo for the website.
> > > > http://www.apache.org/dev/project-site.html
> > > >
> > > > The one I created is based off the Jekyll template as discussed here.
> > > >
> https://incubator.apache.org/guides/sites.html#publishing_your_website
> > >
>

Re: User Email Account

[Xiang Xiao]

issues@ is a good name, let's follow the convention.

On Sat, Dec 28, 2019 at 1:06 AM Abdelatif Guettouche
 wrote:
>
> > The dev list traffic may reduce after we finish the workflow discussion.
> > but email from GibBox will become more and more, can we send them to
> > rev...@nuttx.apache.org to avoid the review message mess up the dev
> > list?
>
> While reading some projects' board reports, I came across this:
>
> > Gitbox traffic is now going to issues@. The community was losing dev@
> >  subscribers because of the high volume of traffic from Gitbox.
>
> Once we are all set up and ready to receive patches/PRs, we may run
> into the same issue.
>
>
> On Thu, Dec 26, 2019 at 1:34 PM Xiang Xiao  wrote:
> >
> > The dev list traffic may reduce after we finish the workflow discussion.
> > but email from GibBox will become more and more, can we send them to
> > rev...@nuttx.apache.org to avoid the review message mess up the dev
> > list?
> >
> > Thanks
> > Xiang
> >
> > On Thu, Dec 26, 2019 at 8:19 PM spudaneco  wrote:
> > >
> > > I may grumble a bit bur I always follow Justin's advice.I do think that
> > > NuttX is diferent from other new podlings because  began with a huge user
> > > base and has a few different needs on day 1 as a mature project.I don't
> > > believe that finding new committers will be a problem.Sent from Samsung
> > > tablet.
> > >  Original message From: Adam Feuer  Date:
> > > 12/26/19  1:23 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: User
> > > Email Account I think what Justin is saying is that it's going to seem 
> > > like
> > > uncomfortablechaos for a bit, but will eventually settle down into a 
> > > better
> > > state.From what I know about well-functioning teams, that seems right.
> > > Form,storm, norm,
> > > perform.
> > > :)cheersadamOn Wed, Dec 25, 2019 at 8:28 PM Justin Mclean
> > > wrote:> Hi,>> Most of those are not current
> > > incubating projects. Some of them did not> become to level projects. Just
> > > about all did not start with user lists.> Creating a seperate user list 
> > > this
> > > early in previous incubating projects> has slowed or hindered their
> > > community growth. You want users involved so> that they become committers.
> > > At no point have I said you can't do this but> the PPMC needs to carefully
> > > consider it. My Internet access is limited> right now but if you search on
> > > the incubator general list you'll see> several discussions on this.>>
> > > Thanks,> Justin>-- Adam Feuer 

Re: Apache NuttX website

[Xiang Xiao]

Sure.

On Sat, Dec 28, 2019 at 1:22 AM Brennan Ashton
 wrote:
>
> That worked perfect.  Xiang you should be able to assign things to me now.
>
> On Fri, Dec 27, 2019, 8:06 AM Abdelatif Guettouche <
> abdelatif.guettou...@gmail.com> wrote:
>
> > Did you try this one: https://id.apache.org/
> >
> > On Fri, Dec 27, 2019 at 4:04 PM Brennan Ashton
> >  wrote:
> > >
> > > Unfortunately that website requires you to double click to edit fields
> > > (what?) which I cannot do on mobile, so I will have to wait until
> > Saturday
> > > or Sunday to do that You can tag me @btashton for now.
> > >
> > > On Fri, Dec 27, 2019, 5:49 AM Xiang Xiao 
> > wrote:
> > >
> > > > Brennan, could you associate your apache and github account here?
> > > > https://whimsy.apache.org/roster/committer/btashton
> > > > And enable 2FA here:
> > > > https://gitbox.apache.org/setup/
> > > > So you can review the future website related patch.
> > > > The web technology is far beyond my knowledge, I can't do the depth
> > > > review except the typo error.
> > > >
> > > > Thanks
> > > > Xiang
> > > >
> > > > On Sat, Dec 21, 2019 at 12:54 PM Brennan Ashton
> > > >  wrote:
> > > > >
> > > > > Could we create the repo for the website.
> > > > > http://www.apache.org/dev/project-site.html
> > > > >
> > > > > The one I created is based off the Jekyll template as discussed here.
> > > > >
> > https://incubator.apache.org/guides/sites.html#publishing_your_website
> > > >
> >

Re: User Email Account

[Alan Carvalho de Assis]

I think is it a good idea! It will avoid increase the volume of emails
to dev@ list.

BR,

Alan

On 12/27/19, Abdelatif Guettouche  wrote:
>> The dev list traffic may reduce after we finish the workflow discussion.
>> but email from GibBox will become more and more, can we send them to
>> rev...@nuttx.apache.org to avoid the review message mess up the dev
>> list?
>
> While reading some projects' board reports, I came across this:
>
>> Gitbox traffic is now going to issues@. The community was losing dev@
>>  subscribers because of the high volume of traffic from Gitbox.
>
> Once we are all set up and ready to receive patches/PRs, we may run
> into the same issue.
>
>
> On Thu, Dec 26, 2019 at 1:34 PM Xiang Xiao 
> wrote:
>>
>> The dev list traffic may reduce after we finish the workflow discussion.
>> but email from GibBox will become more and more, can we send them to
>> rev...@nuttx.apache.org to avoid the review message mess up the dev
>> list?
>>
>> Thanks
>> Xiang
>>
>> On Thu, Dec 26, 2019 at 8:19 PM spudaneco  wrote:
>> >
>> > I may grumble a bit bur I always follow Justin's advice.I do think that
>> > NuttX is diferent from other new podlings because  began with a huge
>> > user
>> > base and has a few different needs on day 1 as a mature project.I don't
>> > believe that finding new committers will be a problem.Sent from Samsung
>> > tablet.
>> >  Original message From: Adam Feuer 
>> > Date:
>> > 12/26/19  1:23 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re:
>> > User
>> > Email Account I think what Justin is saying is that it's going to seem
>> > like
>> > uncomfortablechaos for a bit, but will eventually settle down into a
>> > better
>> > state.From what I know about well-functioning teams, that seems right.
>> > Form,storm, norm,
>> > perform.
>> > :)cheersadamOn Wed, Dec 25, 2019 at 8:28 PM Justin Mclean
>> > wrote:> Hi,>> Most of those are not current
>> > incubating projects. Some of them did not> become to level projects.
>> > Just
>> > about all did not start with user lists.> Creating a seperate user list
>> > this
>> > early in previous incubating projects> has slowed or hindered their
>> > community growth. You want users involved so> that they become
>> > committers.
>> > At no point have I said you can't do this but> the PPMC needs to
>> > carefully
>> > consider it. My Internet access is limited> right now but if you search
>> > on
>> > the incubator general list you'll see> several discussions on this.>>
>> > Thanks,> Justin>-- Adam Feuer 
>

Re: User Email Account

[Alin Jerpelea]

sounds like a good ideea
lets hope that we can still maintain the dev focus with less distraction

On Fri, Dec 27, 2019, 19:43 Alan Carvalho de Assis 
wrote:

> I think is it a good idea! It will avoid increase the volume of emails
> to dev@ list.
>
> BR,
>
> Alan
>
> On 12/27/19, Abdelatif Guettouche  wrote:
> >> The dev list traffic may reduce after we finish the workflow discussion.
> >> but email from GibBox will become more and more, can we send them to
> >> rev...@nuttx.apache.org to avoid the review message mess up the dev
> >> list?
> >
> > While reading some projects' board reports, I came across this:
> >
> >> Gitbox traffic is now going to issues@. The community was losing dev@
> >>  subscribers because of the high volume of traffic from Gitbox.
> >
> > Once we are all set up and ready to receive patches/PRs, we may run
> > into the same issue.
> >
> >
> > On Thu, Dec 26, 2019 at 1:34 PM Xiang Xiao 
> > wrote:
> >>
> >> The dev list traffic may reduce after we finish the workflow discussion.
> >> but email from GibBox will become more and more, can we send them to
> >> rev...@nuttx.apache.org to avoid the review message mess up the dev
> >> list?
> >>
> >> Thanks
> >> Xiang
> >>
> >> On Thu, Dec 26, 2019 at 8:19 PM spudaneco  wrote:
> >> >
> >> > I may grumble a bit bur I always follow Justin's advice.I do think
> that
> >> > NuttX is diferent from other new podlings because  began with a huge
> >> > user
> >> > base and has a few different needs on day 1 as a mature project.I
> don't
> >> > believe that finding new committers will be a problem.Sent from
> Samsung
> >> > tablet.
> >> >  Original message From: Adam Feuer 
> >> > Date:
> >> > 12/26/19  1:23 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re:
> >> > User
> >> > Email Account I think what Justin is saying is that it's going to seem
> >> > like
> >> > uncomfortablechaos for a bit, but will eventually settle down into a
> >> > better
> >> > state.From what I know about well-functioning teams, that seems right.
> >> > Form,storm, norm,
> >> > perform.<
> https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development>
> >> > :)cheersadamOn Wed, Dec 25, 2019 at 8:28 PM Justin Mclean
> >> > wrote:> Hi,>> Most of those are not current
> >> > incubating projects. Some of them did not> become to level projects.
> >> > Just
> >> > about all did not start with user lists.> Creating a seperate user
> list
> >> > this
> >> > early in previous incubating projects> has slowed or hindered their
> >> > community growth. You want users involved so> that they become
> >> > committers.
> >> > At no point have I said you can't do this but> the PPMC needs to
> >> > carefully
> >> > consider it. My Internet access is limited> right now but if you
> search
> >> > on
> >> > the incubator general list you'll see> several discussions on this.>>
> >> > Thanks,> Justin>-- Adam Feuer 
> >
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Nathan Hartman]

On Fri, Dec 27, 2019 at 10:45 AM Xiang Xiao  wrote:
> On Fri, Dec 27, 2019 at 10:59 PM David Sidrane  
> wrote:
> > Notice what happened in the repo.
>
> Yes, you manually create a branch in official repo without any review process.
>
> > See https://github.com/apache/incubator-nuttx-website/branches
> >
> > Now do you see why the argument makes sense?
> >
>
> No, since the normal contributor even don't have right to modify
> anything in official repo. Only committer can hit this issue, you just
> abuse the committer power.
> This also demonstrate PX4 workflow encourage people modify the
> official repo directly just like local fork, I don't think it's a good
> habit.
>
> > Are we going to prohibit this? Think about the ramification. We as
> > committers will not be able to use the UI when it makes sense.
>
> Of course, we should prohibit any modification which doesn't pass the
> review process like this enter the repo.
> You can do anything in your fork with UI, but shouldn't mess up the
> official repo.
> Many people will sync up with the official repo, any partial or stale
> work just make the newbie confusion.

Exactly.

Any changes you want to make (whether you are a committer or not):
* If you are using GitHub, make a fork, make your changes in your
fork, open a PR.
* If you are using git, make a clone, make your changes in your clone,
send a 'git request-pull' or 'git format-patch'.
* If you are using no SCM / other SCM, get the release tarball, make
your changes, produce a patch.

Committers are not allowed to bypass the above and put stuff directly
in the repo without going through the same process and review as
everyone else.

Nathan

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Alin Jerpelea]

this is a simple workflow that can fit everybody
+1

On Fri, Dec 27, 2019, 22:28 Nathan Hartman  wrote:

> On Fri, Dec 27, 2019 at 10:45 AM Xiang Xiao 
> wrote:
> > On Fri, Dec 27, 2019 at 10:59 PM David Sidrane 
> wrote:
> > > Notice what happened in the repo.
> >
> > Yes, you manually create a branch in official repo without any review
> process.
> >
> > > See https://github.com/apache/incubator-nuttx-website/branches
> > >
> > > Now do you see why the argument makes sense?
> > >
> >
> > No, since the normal contributor even don't have right to modify
> > anything in official repo. Only committer can hit this issue, you just
> > abuse the committer power.
> > This also demonstrate PX4 workflow encourage people modify the
> > official repo directly just like local fork, I don't think it's a good
> > habit.
> >
> > > Are we going to prohibit this? Think about the ramification. We as
> > > committers will not be able to use the UI when it makes sense.
> >
> > Of course, we should prohibit any modification which doesn't pass the
> > review process like this enter the repo.
> > You can do anything in your fork with UI, but shouldn't mess up the
> > official repo.
> > Many people will sync up with the official repo, any partial or stale
> > work just make the newbie confusion.
>
> Exactly.
>
> Any changes you want to make (whether you are a committer or not):
> * If you are using GitHub, make a fork, make your changes in your
> fork, open a PR.
> * If you are using git, make a clone, make your changes in your clone,
> send a 'git request-pull' or 'git format-patch'.
> * If you are using no SCM / other SCM, get the release tarball, make
> your changes, produce a patch.
>
> Committers are not allowed to bypass the above and put stuff directly
> in the repo without going through the same process and review as
> everyone else.
>
> Nathan
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[spudaneco]

+1Singin' to choir!Sent from my Samsung Galaxy smartphone.
null

[GitHub] [incubator-nuttx] davids5 opened a new pull request #12: nxstyle improvements with No tooling

[GitBox]

davids5 opened a new pull request #12: nxstyle improvements with No tooling
URL: https://github.com/apache/incubator-nuttx/pull/12
 
 
   - Added features
  - outputs parse-able compiler like error format
  - Uses getops to parse command line.
  - Supports
   -s silence all output
   -g provide a PASS fail message
   
   test script to check the whole of nuttx
   ```
   #!/bin/bash
   
   LIST=$(find ../ -type f \( -iname \*.c -o -iname \*.h \))
   for f in $LIST; do 
   ./nxstyle -g -m 80 $f; 
   done
   ```
   Good new 4000 files pass.
   ```
   ./test.sh 2>&1 | grep PASSED | wc -l
   4000
   ```
   BAD new 5298 files fail.
   ```
   ./test.sh  2>&1 | grep FAIL | wc -l
   5298
   ```
   
   # Test cases
   
   ## Test case 1
   ironic but true
   `./nxstyle  -m 99 nxstyle-master.c `
   ```
   nxstyle-master.c:316:11: error: Bad alignment
   nxstyle-master.c:319:13: error: Bad left brace alignment
   nxstyle-master.c:320:15: error: Bad comment alignment
   nxstyle-master.c:321:16: error: Bad comment block alignment
   nxstyle-master.c:322:16: error: Bad comment block alignment
   nxstyle-master.c:323:16: error: Bad comment block alignment
   nxstyle-master.c:325:15: error: Bad alignment
   nxstyle-master.c:329:17: error: Bad left brace alignment
   nxstyle-master.c:333:17: error: Bad right brace alignment
   nxstyle-master.c:335:15: error: Bad comment alignment
   nxstyle-master.c:336:16: error: Bad comment block alignment
   nxstyle-master.c:337:16: error: Bad comment block alignment
   nxstyle-master.c:338:16: error: Bad comment block alignment
   nxstyle-master.c:339:16: error: Bad comment block alignment
   nxstyle-master.c:341:15: error: Bad alignment
   nxstyle-master.c:342:17: error: Bad left brace alignment
   nxstyle-master.c:345:19: error: Bad alignment
   nxstyle-master.c:346:21: error: Bad left brace alignment
   nxstyle-master.c:347:21: error: Bad right brace alignment
   nxstyle-master.c:349:19: error: Bad alignment
   nxstyle-master.c:351:21: error: Bad left brace alignment
   nxstyle-master.c:353:21: error: Bad right brace alignment
   nxstyle-master.c:354:17: error: Bad right brace alignment
   nxstyle-master.c:355:13: error: Bad right brace alignment
   nxstyle-master.c:406:1: error: Missing blank line after comment
   nxstyle-master.c:480:10: error: C++ style comment
   nxstyle-master.c:540:1: error: Missing blank line after comment
   nxstyle-master.c:609:0: error: C++ style comment
   nxstyle-master.c:609:0: error: No indentation line
   nxstyle-master.c:611:0: error: C++ style comment
   nxstyle-master.c:611:0: error: No indentation line
   nxstyle-master.c:617:0: error: C++ style comment
   nxstyle-master.c:617:0: error: No indentation line
   nxstyle-master.c:891:100: error: Long line found
   nxstyle-master.c:1189:1: error: Too many blank lines
   nxstyle-master.c:1211:56: error: Missing space before closing C comment
   nxstyle-master.c:1330:1: error: Missing blank line before comment found
   nxstyle-master.c:1356:1: error: Missing blank line before comment found
   nxstyle-master.c:1405:1: error: Missing blank line before comment found
   nxstyle-master.c:1446:1: error: Missing blank line before comment found
   nxstyle-master.c:1474:105: error: Long line found
   nxstyle-master.c:1501:1: error: Missing blank line before comment found
   nxstyle-master.c:1516:1: error: Missing blank line before comment found
   nxstyle-master.c:1544:1: error: Missing blank line before comment found
   nxstyle-master.c:1572:1: error: Missing blank line before comment found
   nxstyle-master.c:1592:1: error: Missing blank line before comment found
   nxstyle-master.c:1607:1: error: Missing blank line before comment found
   nxstyle-master.c:1626:1: error: Missing blank line before comment found
   nxstyle-master.c:1744:38: error: Operator/assignment must be preceded with 
whitespace
   ```
   
   ## Test case 2
   blank.c
   `nxstyle -m 90 blank.c`
   45 lines of /n
   ```
   ...
   ```
   ` ./nxstyle  -m 80 blank.c `
   ```
   blank.c:1:1: error: File begins with a blank line
   blank.c:2:1: error: Too many blank lines
   blank.c:3:1: error: Too many blank lines
   blank.c:4:1: error: Too many blank lines
   blank.c:5:1: error: Too many blank lines
   blank.c:6:1: error: Too many blank lines
   blank.c:7:1: error: Too many blank lines
   blank.c:8:1: error: Too many blank lines
   blank.c:9:1: error: Too many blank lines
   blank.c:10:1: error: Too many blank lines
   blank.c:11:1: error: Too many blank lines
   blank.c:12:1: error: Too many blank lines
   blank.c:13:1: error: Too many blank lines
   blank.c:14:1: error: Too many blank lines
   blank.c:15:1: error: Too many blank lines
   blank.c:16:1: error: Too many blank lines
   blank.c:17:1: error: Too many blank lines
   blank.c:18:1: error: Too many blank lines
   blank.c:19:1: error: Too many blank lines
   blank.c:20:1: error: Too many blank lines
   blank.c:21:1: error: Too many blank lines
   blank.c:22

Re: Booting NuttX on SAMA5D27-XULT

[Adam Feuer]

I got this to appear on UART2:

NuttShell (NSH)
> Welcome to NuttX on the SAMA5D27-XULT :)
> nsh>
>

But it doesn't accept any input.

Here's the changes I had to do to make it get this far:

https://github.com/apache/incubator-nuttx/compare/master...adamfeuer:feature/sama5d27-xult-improvements

So NSH seems to be able to send output, but not read input. Any ideas about
this...?

I guess to prepare for the GiantBoard I should try to get the NSH console
onto one of the FlexComs...

cheers
adam

On Thu, Dec 26, 2019 at 6:42 PM Adam Feuer  wrote:

> Greg,
>
> Ok, I wired up an FTDI USB converter to UART0... PB27 (UTXD0) and PB26
> (UTXR0). That also didn't work. H.
>
> I'll think about it some more. Thanks again for the help.
>
> cheers
> adam
>
> On Thu, Dec 26, 2019 at 6:30 PM Gregory Nutt  wrote:
>
>>
>> > Ok, I used the menuconfig system to set the serial console to UART1,
>> 57600
>> > baud rate.
>> >
>> > The system boots, hits the nsh_main breakpoint, I can continue to fputs,
>> > and then if I continue, then break, the system stops in the idle loop.
>> So
>> > it seems like it's running, but the serial console isn't working, at
>> least
>> > on the DEBUG port. If I boot into Linux, I can get a console login on
>> the
>> > DEBUG port at 115200 baud.
>> >
>> > When I boot NuttX, I don't get any response from the serial terminal. I
>> can
>> > see I'm transmitting because the lights on my FTDI console blink.
>> >
>> > The SAMA5D27 pinout definitely says that UTXD1 is UART1; and that's what
>> > the embedded debugger is connected to... so I'm confused.
>> >
>> > Any more ideas?
>>
>> Not really.
>>
>> It is in the IDLE loop because there is nothing to do.  This is a
>> symptom of UART1 no working as it is supposed to.  There are a few
>> things to check.  Usually the problem is with pin configuration or with
>> jumper settings
>>
>> First, check the jumpers.  In 5.4.14 it looks like you would need:
>>
>> Pin J9 *NOT* tied to ground
>> Jumper JP1 *NOT* installed
>> Jumper JP2 DEBUG_DIS ON
>>
>> Then double check the pin configurations.
>>
>> In the schematic, I see that the connection to the CDC/ACM VCOM is via
>> DBGU_UXTD1_PD3 and
>> DBGU_URXD1_PD2.
>>
>> The UART1 pins must defined in the board.h file.  I see
>>
>> #define PIO_UART1_RXD  PIO_UART1_RXD_1
>> #define PIO_UART1_TXD  PIO_UART1_TXD_1
>>
>> And if I look in arch/arm/src/sama5/hardware/_sama5d2x_pinmap.h, I see
>>
>> PIO_UART1_RXD_1 is pin PD2
>> PIO_UART1_TXD_1 is pin PD3
>>
>> So that looks okay.
>>
>> You can try UART2 if you like.  Sometimes EDGB VCOM interfaces are
>> mysterious.  On UART2 you could at least look at what is the TX pin to
>> see if anything is coming out.  Careful with pin configurations!
>>
>> Greg
>>
>>
>
> --
> Adam Feuer 
>


-- 
Adam Feuer 

Re: Booting NuttX on SAMA5D27-XULT

[Adam Feuer]

Does NSH wait for an interrupt from the UART to read data? If so, maybe the
SAMA5D27 isn't interrupting. I tried to enable PIOD interrupts, since UART2
is on PIOD, but got some compilation errors. I'll look at it more tomorrow.

cheers
adam

On Thu, Dec 26, 2019 at 11:46 PM Adam Feuer  wrote:

> I got this to appear on UART2:
>
> NuttShell (NSH)
>> Welcome to NuttX on the SAMA5D27-XULT :)
>> nsh>
>>
>
> But it doesn't accept any input.
>
> Here's the changes I had to do to make it get this far:
>
>
> https://github.com/apache/incubator-nuttx/compare/master...adamfeuer:feature/sama5d27-xult-improvements
>
> So NSH seems to be able to send output, but not read input. Any ideas
> about this...?
>
> I guess to prepare for the GiantBoard I should try to get the NSH console
> onto one of the FlexComs...
>
> cheers
> adam
>
> On Thu, Dec 26, 2019 at 6:42 PM Adam Feuer  wrote:
>
>> Greg,
>>
>> Ok, I wired up an FTDI USB converter to UART0... PB27 (UTXD0) and PB26
>> (UTXR0). That also didn't work. H.
>>
>> I'll think about it some more. Thanks again for the help.
>>
>> cheers
>> adam
>>
>> On Thu, Dec 26, 2019 at 6:30 PM Gregory Nutt  wrote:
>>
>>>
>>> > Ok, I used the menuconfig system to set the serial console to UART1,
>>> 57600
>>> > baud rate.
>>> >
>>> > The system boots, hits the nsh_main breakpoint, I can continue to
>>> fputs,
>>> > and then if I continue, then break, the system stops in the idle loop.
>>> So
>>> > it seems like it's running, but the serial console isn't working, at
>>> least
>>> > on the DEBUG port. If I boot into Linux, I can get a console login on
>>> the
>>> > DEBUG port at 115200 baud.
>>> >
>>> > When I boot NuttX, I don't get any response from the serial terminal.
>>> I can
>>> > see I'm transmitting because the lights on my FTDI console blink.
>>> >
>>> > The SAMA5D27 pinout definitely says that UTXD1 is UART1; and that's
>>> what
>>> > the embedded debugger is connected to... so I'm confused.
>>> >
>>> > Any more ideas?
>>>
>>> Not really.
>>>
>>> It is in the IDLE loop because there is nothing to do.  This is a
>>> symptom of UART1 no working as it is supposed to.  There are a few
>>> things to check.  Usually the problem is with pin configuration or with
>>> jumper settings
>>>
>>> First, check the jumpers.  In 5.4.14 it looks like you would need:
>>>
>>> Pin J9 *NOT* tied to ground
>>> Jumper JP1 *NOT* installed
>>> Jumper JP2 DEBUG_DIS ON
>>>
>>> Then double check the pin configurations.
>>>
>>> In the schematic, I see that the connection to the CDC/ACM VCOM is via
>>> DBGU_UXTD1_PD3 and
>>> DBGU_URXD1_PD2.
>>>
>>> The UART1 pins must defined in the board.h file.  I see
>>>
>>> #define PIO_UART1_RXD  PIO_UART1_RXD_1
>>> #define PIO_UART1_TXD  PIO_UART1_TXD_1
>>>
>>> And if I look in arch/arm/src/sama5/hardware/_sama5d2x_pinmap.h, I see
>>>
>>> PIO_UART1_RXD_1 is pin PD2
>>> PIO_UART1_TXD_1 is pin PD3
>>>
>>> So that looks okay.
>>>
>>> You can try UART2 if you like.  Sometimes EDGB VCOM interfaces are
>>> mysterious.  On UART2 you could at least look at what is the TX pin to
>>> see if anything is coming out.  Careful with pin configurations!
>>>
>>> Greg
>>>
>>>
>>
>> --
>> Adam Feuer 
>>
>
>
> --
> Adam Feuer 
>


-- 
Adam Feuer 

Re: Booting NuttX on SAMA5D27-XULT

[Adam Feuer]

Looks like the SAMA5D2x PIO controller differs from the SAMA5D3x and D4x
PIO controllers. So the PIO/ISR configuration probably needs to be updated.
I'm giving this a shot, but not sure how best to tackle this. Should I look
at the Linux4SAM code? Or is reading the datasheet the best way to go?
Deciphering that is pretty slow going.

cheers
adam

On Fri, Dec 27, 2019 at 1:04 AM Adam Feuer  wrote:

> Does NSH wait for an interrupt from the UART to read data? If so, maybe
> the SAMA5D27 isn't interrupting. I tried to enable PIOD interrupts, since
> UART2 is on PIOD, but got some compilation errors. I'll look at it more
> tomorrow.
>
> cheers
> adam
>
> On Thu, Dec 26, 2019 at 11:46 PM Adam Feuer  wrote:
>
>> I got this to appear on UART2:
>>
>> NuttShell (NSH)
>>> Welcome to NuttX on the SAMA5D27-XULT :)
>>> nsh>
>>>
>>
>> But it doesn't accept any input.
>>
>> Here's the changes I had to do to make it get this far:
>>
>>
>> https://github.com/apache/incubator-nuttx/compare/master...adamfeuer:feature/sama5d27-xult-improvements
>>
>> So NSH seems to be able to send output, but not read input. Any ideas
>> about this...?
>>
>> I guess to prepare for the GiantBoard I should try to get the NSH console
>> onto one of the FlexComs...
>>
>> cheers
>> adam
>>
>> On Thu, Dec 26, 2019 at 6:42 PM Adam Feuer  wrote:
>>
>>> Greg,
>>>
>>> Ok, I wired up an FTDI USB converter to UART0... PB27 (UTXD0) and PB26
>>> (UTXR0). That also didn't work. H.
>>>
>>> I'll think about it some more. Thanks again for the help.
>>>
>>> cheers
>>> adam
>>>
>>> On Thu, Dec 26, 2019 at 6:30 PM Gregory Nutt 
>>> wrote:
>>>

 > Ok, I used the menuconfig system to set the serial console to UART1,
 57600
 > baud rate.
 >
 > The system boots, hits the nsh_main breakpoint, I can continue to
 fputs,
 > and then if I continue, then break, the system stops in the idle
 loop. So
 > it seems like it's running, but the serial console isn't working, at
 least
 > on the DEBUG port. If I boot into Linux, I can get a console login on
 the
 > DEBUG port at 115200 baud.
 >
 > When I boot NuttX, I don't get any response from the serial terminal.
 I can
 > see I'm transmitting because the lights on my FTDI console blink.
 >
 > The SAMA5D27 pinout definitely says that UTXD1 is UART1; and that's
 what
 > the embedded debugger is connected to... so I'm confused.
 >
 > Any more ideas?

 Not really.

 It is in the IDLE loop because there is nothing to do.  This is a
 symptom of UART1 no working as it is supposed to.  There are a few
 things to check.  Usually the problem is with pin configuration or with
 jumper settings

 First, check the jumpers.  In 5.4.14 it looks like you would need:

 Pin J9 *NOT* tied to ground
 Jumper JP1 *NOT* installed
 Jumper JP2 DEBUG_DIS ON

 Then double check the pin configurations.

 In the schematic, I see that the connection to the CDC/ACM VCOM is via
 DBGU_UXTD1_PD3 and
 DBGU_URXD1_PD2.

 The UART1 pins must defined in the board.h file.  I see

 #define PIO_UART1_RXD  PIO_UART1_RXD_1
 #define PIO_UART1_TXD  PIO_UART1_TXD_1

 And if I look in arch/arm/src/sama5/hardware/_sama5d2x_pinmap.h, I see

 PIO_UART1_RXD_1 is pin PD2
 PIO_UART1_TXD_1 is pin PD3

 So that looks okay.

 You can try UART2 if you like.  Sometimes EDGB VCOM interfaces are
 mysterious.  On UART2 you could at least look at what is the TX pin to
 see if anything is coming out.  Careful with pin configurations!

 Greg


>>>
>>> --
>>> Adam Feuer 
>>>
>>
>>
>> --
>> Adam Feuer 
>>
>
>
> --
> Adam Feuer 
>


-- 
Adam Feuer 

Re: Booting NuttX on SAMA5D27-XULT

[Adam Feuer]

Greg,

This Microchip Atmel Github repo atmel-software-package
 has a bunch of
example code for configuring the PIOs and interrupts for SAMA5D2 and
SAMA5D3. It's seems different from the NuttX SAMA5 D2 and D3/D4 code.

>From looking at this repo, D2, D3, and D4 chips seem to use an AIC5
interrupt controller unit, just with different offsets. So the interrupt
code could follow the Atmel aic5.c

driver file. I tried to compile the code but am getting link errors about
my elf executables not using VFP while the other files are. I'll try to
track that down.

The USART example
shows
that interrupts need to be enabled, so it does seem that this is probably
the problem with the serial port not getting any input data– its USART
interrupts are probably not initialized.

Do you have any ideas, comments, or thoughts? Am I going in the right
direction?

cheers
adam

On Fri, Dec 27, 2019 at 11:42 AM Adam Feuer  wrote:

> Looks like the SAMA5D2x PIO controller differs from the SAMA5D3x and D4x
> PIO controllers. So the PIO/ISR configuration probably needs to be updated.
> I'm giving this a shot, but not sure how best to tackle this. Should I look
> at the Linux4SAM code? Or is reading the datasheet the best way to go?
> Deciphering that is pretty slow going.
>
> cheers
> adam
>
> On Fri, Dec 27, 2019 at 1:04 AM Adam Feuer  wrote:
>
>> Does NSH wait for an interrupt from the UART to read data? If so, maybe
>> the SAMA5D27 isn't interrupting. I tried to enable PIOD interrupts, since
>> UART2 is on PIOD, but got some compilation errors. I'll look at it more
>> tomorrow.
>>
>> cheers
>> adam
>>
>> On Thu, Dec 26, 2019 at 11:46 PM Adam Feuer  wrote:
>>
>>> I got this to appear on UART2:
>>>
>>> NuttShell (NSH)
 Welcome to NuttX on the SAMA5D27-XULT :)
 nsh>

>>>
>>> But it doesn't accept any input.
>>>
>>> Here's the changes I had to do to make it get this far:
>>>
>>>
>>> https://github.com/apache/incubator-nuttx/compare/master...adamfeuer:feature/sama5d27-xult-improvements
>>>
>>> So NSH seems to be able to send output, but not read input. Any ideas
>>> about this...?
>>>
>>> I guess to prepare for the GiantBoard I should try to get the NSH
>>> console onto one of the FlexComs...
>>>
>>> cheers
>>> adam
>>>
>>> On Thu, Dec 26, 2019 at 6:42 PM Adam Feuer  wrote:
>>>
 Greg,

 Ok, I wired up an FTDI USB converter to UART0... PB27 (UTXD0) and PB26
 (UTXR0). That also didn't work. H.

 I'll think about it some more. Thanks again for the help.

 cheers
 adam

 On Thu, Dec 26, 2019 at 6:30 PM Gregory Nutt 
 wrote:

>
> > Ok, I used the menuconfig system to set the serial console to UART1,
> 57600
> > baud rate.
> >
> > The system boots, hits the nsh_main breakpoint, I can continue to
> fputs,
> > and then if I continue, then break, the system stops in the idle
> loop. So
> > it seems like it's running, but the serial console isn't working, at
> least
> > on the DEBUG port. If I boot into Linux, I can get a console login
> on the
> > DEBUG port at 115200 baud.
> >
> > When I boot NuttX, I don't get any response from the serial
> terminal. I can
> > see I'm transmitting because the lights on my FTDI console blink.
> >
> > The SAMA5D27 pinout definitely says that UTXD1 is UART1; and that's
> what
> > the embedded debugger is connected to... so I'm confused.
> >
> > Any more ideas?
>
> Not really.
>
> It is in the IDLE loop because there is nothing to do.  This is a
> symptom of UART1 no working as it is supposed to.  There are a few
> things to check.  Usually the problem is with pin configuration or
> with
> jumper settings
>
> First, check the jumpers.  In 5.4.14 it looks like you would need:
>
> Pin J9 *NOT* tied to ground
> Jumper JP1 *NOT* installed
> Jumper JP2 DEBUG_DIS ON
>
> Then double check the pin configurations.
>
> In the schematic, I see that the connection to the CDC/ACM VCOM is via
> DBGU_UXTD1_PD3 and
> DBGU_URXD1_PD2.
>
> The UART1 pins must defined in the board.h file.  I see
>
> #define PIO_UART1_RXD  PIO_UART1_RXD_1
> #define PIO_UART1_TXD  PIO_UART1_TXD_1
>
> And if I look in arch/arm/src/sama5/hardware/_sama5d2x_pinmap.h, I see
>
> PIO_UART1_RXD_1 is pin PD2
> PIO_UART1_TXD_1 is pin PD3
>
> So that looks okay.
>
> You can try UART2 if you like.  Sometimes EDGB VCOM interfaces are
> mysterious.  On UART2 you could at least look at what is the TX pin to
> see if anything is coming out.  Careful with pin configurations!
>
> Greg
>
>

 --
 Adam Feuer 

>>>
>>>

Re: Booting NuttX on SAMA5D27-XULT

[Gregory Nutt]

I got this to appear on UART2:

NuttShell (NSH)

Welcome to NuttX on the SAMA5D27-XULT :)
nsh>


But it doesn't accept any input.

Here's the changes I had to do to make it get this far:

https://github.com/apache/incubator-nuttx/compare/master...adamfeuer:feature/sama5d27-xult-improvements


The change to arch/arm/src/sama5/hardware/_sama5d2x_pinmap.h 
 
is incorrect.  Instead, you need to add this to the 
sama4d2-xplained/include/board.h file:


#define PIO_UART2_RXD PIO_UART2_RXD_3
#define PIO_UART2_TXD PIO_UART2_TXD_3

The pinmap.h should not be modified.

I don't understand the lines you changed to 
arch/arm/src/sama5/sam_config.h 
 
so I am suspicious of that.  I don't really know what you are doing 
there.  Certainly you need to remove the '1' form '# undef 
SAMA5_HAVE_DBGU_CONSOLE 1' in any case.


The changes to arch/arm/src/sama5/sam_serial.c 
 
are certainly important bug fixes.  Can you send those (plus the typo 
fixes) as patches to d...@apache.org -- or submit a PR against 
github.com/apache/incubator-nuttx?

Re: Booting NuttX on SAMA5D27-XULT

[Gregory Nutt]

Does NSH wait for an interrupt from the UART to read data? If so, maybe the
SAMA5D27 isn't interrupting. I tried to enable PIOD interrupts, since UART2
is on PIOD, but got some compilation errors. I'll look at it more tomorrow.


Yes, if you don't have RX interrupts, nothing will be read.  If you 
don't have interrupts there is probably an error in either the pin 
configuration or IRQ number used.

Re: Booting NuttX on SAMA5D27-XULT

[Gregory Nutt]

Looks like the SAMA5D2x PIO controller differs from the SAMA5D3x and D4x
PIO controllers. So the PIO/ISR configuration probably needs to be updated.
I'm giving this a shot, but not sure how best to tackle this. Should I look
at the Linux4SAM code? Or is reading the datasheet the best way to go?
Deciphering that is pretty slow going.


I would not recommend looking at Linux code at all.  First, Linux is to 
complex to follow the logic and second, it is GPL so you are permitted 
to leverage anything from there due to the license:  I would look at the 
IRQ number and the RX pin configuation.

Re: Booting NuttX on SAMA5D27-XULT

[Adam Feuer]

On Fri, Dec 27, 2019 at 3:39 PM Gregory Nutt  wrote:

> #define PIO_UART2_RXD PIO_UART2_RXD_3
> #define PIO_UART2_TXD PIO_UART2_TXD_3
>

I'll try that and revert the pinmap.h files.


> Certainly you need to remove the '1' form '# undef SAMA5_HAVE_DBGU_CONSOLE
> 1' in any case.
>

Thank for catching that, it's a typo.


> The changes to arch/arm/src/sama5/sam_serial.c
> are certainly important bug fixes.  Can you send those (plus the typo
> fixes) as patches to d...@apache.org -- or submit a PR against
> github.com/apache/incubator-nuttx?
>

Yes, I will certainly do that. Do you want them as-is now in a small PR, or
would you rather have them as part of a larger PR when (hopefully!) get the
D27 board working?

Re: the Linux code, thanks for the tips especially about the license. I
will stay out of that. :) What about the Atmel example code? It has an MIT
license.

cheers
adam
-- 
Adam Feuer 

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Disruptive Solutions]

This sounds like it was... clone the repo to local. Do our thing making a 
feature branch.. commit to our own private repo ... Send patch (format patch) 
in (after nxstyle, indent, etc and README addition) and let it reviewed by 
sending it to central channel (was Google Group) and checkout locally to 
master, pull the latest patches from origin/master and do another feature... 
same proces again.

Ben

Verstuurd vanaf mijn iPhone

> Op 27 dec. 2019 om 21:28 heeft Nathan Hartman  het 
> volgende geschreven:
> 
> On Fri, Dec 27, 2019 at 10:45 AM Xiang Xiao  
> wrote:
>>> On Fri, Dec 27, 2019 at 10:59 PM David Sidrane  
>>> wrote:
>>> Notice what happened in the repo.
>> 
>> Yes, you manually create a branch in official repo without any review 
>> process.
>> 
>>> See https://github.com/apache/incubator-nuttx-website/branches
>>> 
>>> Now do you see why the argument makes sense?
>>> 
>> 
>> No, since the normal contributor even don't have right to modify
>> anything in official repo. Only committer can hit this issue, you just
>> abuse the committer power.
>> This also demonstrate PX4 workflow encourage people modify the
>> official repo directly just like local fork, I don't think it's a good
>> habit.
>> 
>>> Are we going to prohibit this? Think about the ramification. We as
>>> committers will not be able to use the UI when it makes sense.
>> 
>> Of course, we should prohibit any modification which doesn't pass the
>> review process like this enter the repo.
>> You can do anything in your fork with UI, but shouldn't mess up the
>> official repo.
>> Many people will sync up with the official repo, any partial or stale
>> work just make the newbie confusion.
> 
> Exactly.
> 
> Any changes you want to make (whether you are a committer or not):
> * If you are using GitHub, make a fork, make your changes in your
> fork, open a PR.
> * If you are using git, make a clone, make your changes in your clone,
> send a 'git request-pull' or 'git format-patch'.
> * If you are using no SCM / other SCM, get the release tarball, make
> your changes, produce a patch.
> 
> Committers are not allowed to bypass the above and put stuff directly
> in the repo without going through the same process and review as
> everyone else.
> 
> Nathan

[GitHub] [incubator-nuttx] adamfeuer opened a new pull request #13: sama3 sam_serial.c USART selection fixes

[GitBox]

adamfeuer opened a new pull request #13: sama3 sam_serial.c USART selection 
fixes
URL: https://github.com/apache/incubator-nuttx/pull/13
 
 
   ### Summary
   
   * Fixes bugs in USART console selection
   * Fixes a few typos in the SAMA5D27 README file
   
   ### Impact
   
   * SAMA5 USART console selection should work correctly now
   
   ### Limitations / TODO
   
   * SAMA5D27 console input still not working due to incomplete port – 
hopefully more changes will come in a future PR
   
   ### Detail
   
   * Looks like these were typos when the port was created
   
   ### Testing
   
   * Manual – compile and run on a SAMA5D27-XULT board by loading using a 
Segger J-Link debugger
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Booting NuttX on SAMA5D27-XULT

[Adam Feuer]

Greg,

Ok, here's the SAMA5 UART selection and typo fix PR:

https://github.com/apache/incubator-nuttx/pull/13

I fixed the rest of the UARTs too. Will you let me know if you have
improvements? I am happy to update the PR.

cheers
adam

On Fri, Dec 27, 2019 at 3:58 PM Adam Feuer  wrote:

> On Fri, Dec 27, 2019 at 3:39 PM Gregory Nutt  wrote:
>
>> #define PIO_UART2_RXD PIO_UART2_RXD_3
>> #define PIO_UART2_TXD PIO_UART2_TXD_3
>>
>
> I'll try that and revert the pinmap.h files.
>
>
>> Certainly you need to remove the '1' form '# undef
>> SAMA5_HAVE_DBGU_CONSOLE 1' in any case.
>>
>
> Thank for catching that, it's a typo.
>
>
>> The changes to arch/arm/src/sama5/sam_serial.c
>> are certainly important bug fixes.  Can you send those (plus the typo
>> fixes) as patches to d...@apache.org -- or submit a PR against
>> github.com/apache/incubator-nuttx?
>>
>
> Yes, I will certainly do that. Do you want them as-is now in a small PR,
> or would you rather have them as part of a larger PR when (hopefully!) get
> the D27 board working?
>
> Re: the Linux code, thanks for the tips especially about the license. I
> will stay out of that. :) What about the Atmel example code? It has an MIT
> license.
>
> cheers
> adam
> --
> Adam Feuer 
>


-- 
Adam Feuer 

[GitHub] [incubator-nuttx] adamfeuer commented on issue #13: sama3 sam_serial.c USART selection fixes

[GitBox]

adamfeuer commented on issue #13: sama3 sam_serial.c USART selection fixes
URL: https://github.com/apache/incubator-nuttx/pull/13#issuecomment-569377932
 
 
   @patacongo I moved the pin disambiguation to `board.h`, thanks for pointing 
this out.
   
   Anything else to improve or correct?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx] xiaoxiang781216 commented on issue #12: nxstyle improvements with No tooling

[GitBox]

xiaoxiang781216 commented on issue #12: nxstyle improvements with No tooling
URL: https://github.com/apache/incubator-nuttx/pull/12#issuecomment-569381487
 
 
   @liuguo09 please take a look.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Podling Nuttx Report Reminder - January 2020

[jmclean]

Dear podling,

This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.

The board meeting is scheduled for Wed, 15 January 2020, 10:30 am PDT.
The report for your podling will form a part of the Incubator PMC
report. The Incubator PMC requires your report to be submitted 2 weeks
before the board meeting, to allow sufficient time for review and
submission (Wed, January 01).

Please submit your report with sufficient time to allow the Incubator
PMC, and subsequently board members to review and digest. Again, the
very latest you should submit your report is 2 weeks prior to the board
meeting.

Candidate names should not be made public before people are actually
elected, so please do not include the names of potential committers or
PPMC members in your report.

Thanks,

The Apache Incubator PMC

Submitting your Report

--

Your report should contain the following:

*   Your project name
*   A brief description of your project, which assumes no knowledge of
the project or necessarily of its field
*   A list of the three most important issues to address in the move
towards graduation.
*   Any issues that the Incubator PMC or ASF Board might wish/need to be
aware of
*   How has the community developed since the last report
*   How has the project developed since the last report.
*   How does the podling rate their own maturity.

This should be appended to the Incubator Wiki page at:

https://cwiki.apache.org/confluence/display/INCUBATOR/January2020

Note: This is manually populated. You may need to wait a little before
this page is created from a template.

Note: The format of the report has changed to use markdown.

Mentors
---

Mentors should review reports for their project(s) and sign them off on
the Incubator wiki page. Signing off reports shows that you are
following the project - projects that are not signed may raise alarms
for the Incubator PMC.

Incubator PMC

Re: Podling Nuttx Report Reminder - January 2020

[Disruptive Solutions]

Nice... Who is going to do this?

Verstuurd vanaf mijn iPhone

> Op 28 dec. 2019 om 06:11 heeft jmcl...@apache.org het volgende geschreven:
> 
> Dear podling,
> 
> This email was sent by an automated system on behalf of the Apache
> Incubator PMC. It is an initial reminder to give you plenty of time to
> prepare your quarterly board report.
> 
> The board meeting is scheduled for Wed, 15 January 2020, 10:30 am PDT.
> The report for your podling will form a part of the Incubator PMC
> report. The Incubator PMC requires your report to be submitted 2 weeks
> before the board meeting, to allow sufficient time for review and
> submission (Wed, January 01).
> 
> Please submit your report with sufficient time to allow the Incubator
> PMC, and subsequently board members to review and digest. Again, the
> very latest you should submit your report is 2 weeks prior to the board
> meeting.
> 
> Candidate names should not be made public before people are actually
> elected, so please do not include the names of potential committers or
> PPMC members in your report.
> 
> Thanks,
> 
> The Apache Incubator PMC
> 
> Submitting your Report
> 
> --
> 
> Your report should contain the following:
> 
> *   Your project name
> *   A brief description of your project, which assumes no knowledge of
>the project or necessarily of its field
> *   A list of the three most important issues to address in the move
>towards graduation.
> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
>aware of
> *   How has the community developed since the last report
> *   How has the project developed since the last report.
> *   How does the podling rate their own maturity.
> 
> This should be appended to the Incubator Wiki page at:
> 
> https://cwiki.apache.org/confluence/display/INCUBATOR/January2020
> 
> Note: This is manually populated. You may need to wait a little before
> this page is created from a template.
> 
> Note: The format of the report has changed to use markdown.
> 
> Mentors
> ---
> 
> Mentors should review reports for their project(s) and sign them off on
> the Incubator wiki page. Signing off reports shows that you are
> following the project - projects that are not signed may raise alarms
> for the Incubator PMC.
> 
> Incubator PMC