[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on a change in pull request #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360791455
 
 

 ##
 File path: tools/check_code_style.sh
 ##
 @@ -0,0 +1,33 @@
+#!/usr/bin/env bash
+
+if [ -z "$1" ]; then
+   FILES=$(git diff master --name-only);
 
 Review comment:
   @xiaoxiang781216 - Right! If you read 
[here](https://github.com/apache/incubator-nuttx/pull/2#issue-356115637) I 
asked for help on the tooling. 
   
   In the absence of a workflow I was assuming a best practices "upstream 
submission" workflow 
   
   It assumes the dev has to checkout "upstream master". Then branches it to 
master-pr-x. Then cherry picks their fork's commits to it. 
   
   At that point the diff is the delta of dev/master-pr-x to 
upstream/master and this is checking for that. 
   
   I think this mimic `git format-patch master` is that not how you submit?
   
   How do you want this to work (what git commands do you use)?


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] davids5 commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on a change in pull request #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360794087
 
 

 ##
 File path: tools/check_code_style.sh
 ##
 @@ -0,0 +1,33 @@
+#!/usr/bin/env bash
+
+if [ -z "$1" ]; then
+   FILES=$(git diff master --name-only);
+else
+   FILES=$1
+fi
+
+DIR=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )
+for FILE in $FILES; do
+  FILENAME=$(basename $FILE)
+  FILE_EXT="${FILENAME#*.}"
+  if [ -f "$FILE" ]; then
+if [ "$FILE_EXT" = "c" ] || [ "$FILE_EXT" = "h" ]; then
+ CHECK_FAILED=$(${DIR}/nxstyle $FILE)
+   #   if [ -n "$CHECK_FAILED" ]; then
+   #   ${DIR}/fix_code_style.sh --quiet < $FILE > $FILE.pretty
+   #
+   #   echo
+   #   git --no-pager diff --no-index --minimal --histogram 
--color=always $FILE $FILE.pretty
+   #   rm -f $FILE.pretty
 
 Review comment:
   @patacongo - we can add a test for git. and address all you other concerns, 
that is not a problem. 
   
   But I think you should think about this again over morning coffee. This does 
not break anyone's build.*  It is a makefile helper and command line option to 
help them ONLY check  the files they changed. They will need git installed to 
do this.
   
   @patacongo It is True it will not work on window util someone who works on 
windows make the changes. I do not work on windows so I will not do this. 
Because I will not be able to test it - and it will be wrong.  I do not add 
Value there. - You could. 


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] davids5 commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on a change in pull request #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360798664
 
 

 ##
 File path: tools/Makefile.unix
 ##
 @@ -697,3 +704,8 @@ apps_distclean:
 ifneq ($(APPDIR),)
$(Q) $(MAKE) -C "$(TOPDIR)/$(APPDIR)" TOPDIR="$(TOPDIR)" distclean
 endif
+
+check_format:
+   $(call colorecho,'Checking NuttX formatting with nxstyle')
+   @$(TOPDIR)/tools/check_code_style.sh
+   @cd "$(SRC_DIR)" && git diff --check
 
 Review comment:
   Yeah I already had thought of that. I had time to think - but not change it. 
The days have been very, very long here with the added overhead of ASF.  
   
   I would like to ask you to contribute. It is far better for building 
community to add value and help with what you know. 
   
   Understanding that using Github is new to you. I woulds suggest you take 
these steps to help. It will reduce the back and forth. it is like ifdef rash 
in code - we should avoid it.
   
   - Be patient - we all that other commitments not just NuttX. Theres is now 
way for a team to move as quickly as you did on you own. 
   
   - Use the [Suggesting Changes on 
GitHub](https://haacked.com/archive/2019/06/03/suggested-changes/) This makes 
your comments the solution as works well for the 
[manini](https://en.wiktionary.org/wiki/manini) stuff.
   - Lean to use the mark up.  You can say 
[ditto](https://github.com/apache/incubator-nuttx/pull/2/files#r360726623) And 
avoid a messy review. 
   You can then link to the NuttX sites coding  standard instead of re typing 
them all the time.
 
   



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] davids5 commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on a change in pull request #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360803384
 
 

 ##
 File path: tools/check_code_style.sh
 ##
 @@ -0,0 +1,33 @@
+#!/usr/bin/env bash
+
 
 Review comment:
   I was looking at this as in incremental steps with reusable pieces that we 
are free to evolve. 
   The real value add in this PR is the ability to fix in ones editor the CS 
violations.
   
   NuttX has no complete CS solution. It is impossible to enforce a CS without 
tools that work 100% and is not go-no-go. for CI and pr-commit hooks.
   
   We should not expect professional developers and new members of the 
community to have to read 10 emails on how each one of the current tools do not 
work and have them understand that the indent.sh will destroy a formatted file. 
What will help is a proper tool like Astyle, Uncurstify, clang-format that can 
detect and FIX the code allong with a few gold standard files (h,c,Kconfig) to 
validate it with.
   
   At this point. I think there are there options.
   
   1. We fix the tooling with all your suggestions.
   2. We remove the tooling commit (I keep them separate on purpose) until we 
have the work flow nailed.
   
   


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] patacongo commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

patacongo commented on a change in pull request #2: Master pr nxstyle 
improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360728789
 
 

 ##
 File path: tools/Makefile.unix
 ##
 @@ -697,3 +704,8 @@ apps_distclean:
 ifneq ($(APPDIR),)
$(Q) $(MAKE) -C "$(TOPDIR)/$(APPDIR)" TOPDIR="$(TOPDIR)" distclean
 endif
+
+check_format:
+   $(call colorecho,'Checking NuttX formatting with nxstyle')
 
 Review comment:
   Unresolved... I don't see the change.


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] davids5 commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on a change in pull request #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360804008
 
 

 ##
 File path: tools/Makefile.unix
 ##
 @@ -697,3 +704,8 @@ apps_distclean:
 ifneq ($(APPDIR),)
$(Q) $(MAKE) -C "$(TOPDIR)/$(APPDIR)" TOPDIR="$(TOPDIR)" distclean
 endif
+
+check_format:
+   $(call colorecho,'Checking NuttX formatting with nxstyle')
 
 Review comment:
   One is enough!


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] davids5 commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on a change in pull request #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360804370
 
 

 ##
 File path: tools/nxstyle.c
 ##
 @@ -140,7 +207,7 @@ int main(int argc, char **argv, char **envp)
 
   maxline  = 78;
   filename = argv[1];
-
+  g_file_name = filename;
   /* Usage:  nxstyle [-m ] 
 
 Review comment:
   ```suggestion
   
 /* Usage:  nxstyle [-m ] 
   ```


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] davids5 commented on issue #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568402453
 
 
   > I added Xiao Xiang to the reviewers. We need to have a lot of concurrence 
here since this PR implements a portion of the workflow while there no workflow 
requirements in place. I think this piece of the workflow is not so 
controversial, but I would like to have Xiang provide his input as well. Xiang 
is the most authorative person on the build system and must be in the loop on 
build system changes.
   
   @patacongo Thank you! 
   
   @xiaoxiang781216  I will add you this organization if you like. Then you can 
free to push commit here.  Or pull this it to upsteam as a **branch** and we 
can all collaborate on it there. What ever get this in.


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: problem booting NuttX on SAMA5D3-Xplained

[Adam Feuer]

Greg,

Thank you so much for the help! I have a Segger J-Link JTAG debugger. I
will try stripping down to a minimal config, and single stepping.

I don't know what UART the debug port is attached to, I will look that up
tomorrow too. Thanks for the pointer to the SAMA5D3x-ek, I haven't looked
at it, I will check it out.

cheers
adam

On Sun, Dec 22, 2019 at 7:57 PM Gregory Nutt  wrote:

> Check the configuration that you are using.  What is the UART used in
> the NuttX configuration for the serial console?  What is the UART that
> connects to the debug port?
>
> Do you have a jtag debugger?  There should be instructions in the README
> explaining how to single step into the OS.  You should be able to
> determine what is failing.  Check the README for the SAMA5D3x-ek too.
> That is a more mature configuration.
>
> So key places to set breakpoints:
>
>   * When you reset, you shard be starting in __start.
>   * At the completion of low level debug, it will call nx_start()
>   * nx_start() will call up_initialize() to finish the hardware
> initialization.
>   * When nx_start()finishes, it will call nsh_main() which should put up
> the the NSH prompt
>
> Do you have networking enabled.  You problem should strip down the
> configuration so that as little as possible is enabled. Disable
> networking, disable USB, etc.
>
> Greg
>
> On 12/22/2019 1:20 AM, Adam Feuer wrote:
> > Ok, maybe more progress. I re-flashed the SPI NOR flash with new files
> from
> > the linux4sam website. Now I can see the serial terminal on the debug
> port
> > during boot. I can stop the boot process using U-Boot, and use U-Boot to
> > load a nuttx.bin image. This process is suggested in the board README.
> >
> > But the system hangs when I execute the go command:
> >
> > U-Boot 2019.04-linux4sam_6.2 (Oct 25 2019 - 00:36:06 +)
> >
> > CPU: SAMA5D36
> > Crystal frequency:   12 MHz
> > CPU clock:  528 MHz
> > Master clock :  132 MHz
> > DRAM:  256 MiB
> > NAND:  256 MiB
> > MMC:   Atmel mci: 0, Atmel mci: 1
> > Loading Environment from NAND... OK
> > In:serial@ee00
> > Out:   serial@ee00
> > Err:   serial@ee00
> > Net:
> > Error: ethernet@f0028000 address not set.
> > eth-1: ethernet@f0028000
> > Error: ethernet@f802c000 address not set.
> > , eth-1: ethernet@f802c000
> > Hit any key to stop autoboot:  0
> > => mmc rescan
> > => fatls mmc 0:1
> >  .Spotlight-V100/
> >1658616   nuttx
> > 106620   nuttx.bin
> >
> > 2 file(s), 1 dir(s)
> >
> > => fatload mmc 0 0x20008000 nuttx.bin
> > 106620 bytes read in 15 ms (6.8 MiB/s)
> > => go 0x20008040
> > ## Starting application at 0x20008040 ...
> >
> > The README file says I should get a NuttX shell here instead of a hang.
> > Does anyone have any ideas how to debug?
> >
> > cheers
> > adam
> >
> > On Sat, Dec 21, 2019 at 9:17 PM Adam Feuer  wrote:
> >
> >> Hi,
> >>
> >> NuttX newbie here.
> >>
> >> I'm trying to load NuttX onto a SAMA5D3-Xplained board. I am trying to
> >> follow the board's README file. I am using the Gnu ARM embedded
> toolchain
> >> v9
> >> <
> https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads
> >
> >> and a Segger J-Link Base JTAG debugger. I have an FTDI USB-serial
> adapter
> >> connected to the board's debug serial port. I compiled NuttX with the
> >> options suggested and debug symbols. My .config file is attached.
> >>
> >> Compiling seems to work and produces executables with debug symbols. I
> am
> >> trying to find a way to boot the board. The README suggests several
> >> options, one is via the debugger. I can boot into linux from an SD Card
> >> using the D36 Linux4Sam instructions
> >> 
> >> and log in using the USB serial port, so I know the board works.
> >>
> >> I can debug using the Segger debugger halting and starting the CPU while
> >> running Linux. The README says, boot the board, halt the CPU, load the
> >> nuttx ELF binary, load the symbols. That seems to work. The Segger
> doesn't
> >> support 'mon pc 0x20008040' like the README suggests, but lists the
> default
> >> start point as 0x20008040... so I just do 'mon go'. I expect a NSH on
> the
> >> debug serial port or the USB serial port, but there's no response either
> >> places.
> >>
> >> My question is:
> >> Should I be able to see a NSH console on the debug serial port? Or the
> USB
> >> serial port? I don't see either devices when I look at the host system's
> >> /dev/ directory.
> >>
> >> cheers
> >> adam
> >>
> >> ps. Here's an excerpt of my gdb session:
> >>
> >> (gdb) mon halt
> >> (gdb) load nuttx
> >> Loading section .text, size 0x19f94 lma 0x20008000
> >> Loading section .ARM.exidx, size 0x8 lma 0x20021f94
> >> Loading section .data, size 0xe0 lma 0x20021f9c
> >> Start address 0x20008040, load size 106620
> >> (gdb) file nuttx
> >> A program is being debugged already.
> >> Are you sure you wa

Re: Simple Workflow Proposal

[Alin Jerpelea]

If we want things to move we need an initial workflow or we risk to be
stuck for weeks debating for a way forward.
This simple workflow should move us forward so that we can improve it over
several iterations.
There are many new things for all of us and no WOW is tested and known to
be our WOW. We must try new things to be able to move forward in the new
structure.


On Sun, Dec 22, 2019, 18:08 Brennan Ashton 
wrote:

> I did not call for a vote because I did not think I could as I'm just a
> community member, I would like my proposal formally voted it on as is.
>
>
> As for the two concerns that I saw raised.
>
> 1) The timeline. Two weeks over the holiday to come to a formal agreement
> is going to be tough and I also don't think just because we have a path
> forward people will stop caring about proposing a better solution.  From
> what I'm seeing the longer term proposal will likely get into the weeds of
> tooling around CI email patches etc... These take weeks to settle on. I
> trust the intentions of the people in the project and do not see a need to
> bind them to a timeline to build this out.
>
> 2) Why cut corners.  Personally I don't see this as cutting corners I think
> this will in practice get us 90% of the way there and get us back into a
> cadence of improving the software.  I trust the project members will use
> judgement within the structure and will actively move the project along to
> better structure.
>
>
> Thanks,
> Brennan
>
>
> On Sun, Dec 22, 2019, 7:08 AM Gregory Nutt  wrote:
>
> > Again, is this a formal vote?  it is not clear to me.  Did someone in
> > the PPMC call a vote?  There is not [VOTE] in the message title?
> >
> > Just  point of order which I do not know the answer too.  Brennan is not
> > yet listed as a PPMC member or a as a committer (but he should be and,
> > hopefully, will be). Can non-PPMC members calls votes that are binding
> > on the PPMC? Just to be clear, I think that someone in the PPMC should
> > call the vote with [VOTE] in the title so that is is clear if we are
> > castubg a binding vote or not for something are not?  Or are we just
> > agreeing in principle or not?
> >
> > Are these binding votes?  We need to clarify what is going on.
> >
> > I think we should stop the habit of using +1 just to indicate we agree
> > with something and we need to enforce the use of [VOTE] in the title so
> > that we know this is a binding vote.
> >
> > On 12/22/2019 7:57 AM, Xiang Xiao wrote:
> > > +1.
> > > It's impotant to let people start the contribution.
> > > The committer could/should do more work to ensure the correction in
> > > review process before the automation tool is ready.
> > >
> > > Thanks
> > > Xiang
> > >
> > > On Sun, Dec 22, 2019 at 8:57 PM David Sidrane 
> > wrote:
> > >> This works!
> > >>
> > >> On 2019/12/22 02:05:56, Brennan Ashton 
> > wrote:
> > >>> I really want to let people to contribute (myself included) ASAP so I
> > was
> > >>> to propose this as an option to get going and can be amended later. I
> > know
> > >>> it does not resolve all the issues, but offers what I think is a
> > reasonable
> > >>> avenue to get started.
> > >>>
> > >>> Submit a PR on GitHub against master if it is approved by one
> commiter
> > >>> (that did not propose it)
> > >> This is key! We need the eyes (and possibly the hands)  of the subject
> > matter experts, reviewing, commenting and possible fixing submissions.
> > >>
> > >>> it can be merged.  The approval is done via the
> > >>> GitHub approval system.
> > >> +1
> > >>> A commiter may create a PR on behalf of a patch submitted to the
> > mailing
> > >>> list.
> > >> +1
> > >>> Commiters can ask for others to review or approve.  But at the end of
> > the
> > >>> day they are the ones who approve and merge.
> > >> +1
> > >>> We can and should amend this later, it is likely not enough long
> term.
> > >>>
> > >>> Could people vote if they think this is fine to start. If you don't
> > agree
> > >>> just note that and we can review where we are at.
> > >>>
> > >>> --Brennan
> > >>>
> >
> >
>

RE: Simple Workflow Proposal

[David Sidrane]

+1 100% agreement

WOW - The Evolve Way of Working (WoW) process (Disciplined Agile (DA))

Please, Please do not assume TLA[1] are known.

We do not all spec the same language here.


-Original Message-
From: Alin Jerpelea [mailto:jerpe...@gmail.com]
Sent: Monday, December 23, 2019 12:41 AM
To: dev@nuttx.apache.org
Subject: Re: Simple Workflow Proposal

If we want things to move we need an initial workflow or we risk to be
stuck for weeks debating for a way forward.
This simple workflow should move us forward so that we can improve it over
several iterations.
There are many new things for all of us and no WOW is tested and known to
be our WOW. We must try new things to be able to move forward in the new
structure.


On Sun, Dec 22, 2019, 18:08 Brennan Ashton 
wrote:

> I did not call for a vote because I did not think I could as I'm just a
> community member, I would like my proposal formally voted it on as is.
>
>
> As for the two concerns that I saw raised.
>
> 1) The timeline. Two weeks over the holiday to come to a formal agreement
> is going to be tough and I also don't think just because we have a path
> forward people will stop caring about proposing a better solution.  From
> what I'm seeing the longer term proposal will likely get into the weeds of
> tooling around CI email patches etc... These take weeks to settle on. I
> trust the intentions of the people in the project and do not see a need to
> bind them to a timeline to build this out.
>
> 2) Why cut corners.  Personally I don't see this as cutting corners I
> think
> this will in practice get us 90% of the way there and get us back into a
> cadence of improving the software.  I trust the project members will use
> judgement within the structure and will actively move the project along to
> better structure.
>
>
> Thanks,
> Brennan
>
>
> On Sun, Dec 22, 2019, 7:08 AM Gregory Nutt  wrote:
>
> > Again, is this a formal vote?  it is not clear to me.  Did someone in
> > the PPMC call a vote?  There is not [VOTE] in the message title?
> >
> > Just  point of order which I do not know the answer too.  Brennan is not
> > yet listed as a PPMC member or a as a committer (but he should be and,
> > hopefully, will be). Can non-PPMC members calls votes that are binding
> > on the PPMC? Just to be clear, I think that someone in the PPMC should
> > call the vote with [VOTE] in the title so that is is clear if we are
> > castubg a binding vote or not for something are not?  Or are we just
> > agreeing in principle or not?
> >
> > Are these binding votes?  We need to clarify what is going on.
> >
> > I think we should stop the habit of using +1 just to indicate we agree
> > with something and we need to enforce the use of [VOTE] in the title so
> > that we know this is a binding vote.
> >
> > On 12/22/2019 7:57 AM, Xiang Xiao wrote:
> > > +1.
> > > It's impotant to let people start the contribution.
> > > The committer could/should do more work to ensure the correction in
> > > review process before the automation tool is ready.
> > >
> > > Thanks
> > > Xiang
> > >
> > > On Sun, Dec 22, 2019 at 8:57 PM David Sidrane 
> > wrote:
> > >> This works!
> > >>
> > >> On 2019/12/22 02:05:56, Brennan Ashton 
> > wrote:
> > >>> I really want to let people to contribute (myself included) ASAP so
> > >>> I
> > was
> > >>> to propose this as an option to get going and can be amended later.
> > >>> I
> > know
> > >>> it does not resolve all the issues, but offers what I think is a
> > reasonable
> > >>> avenue to get started.
> > >>>
> > >>> Submit a PR on GitHub against master if it is approved by one
> commiter
> > >>> (that did not propose it)
> > >> This is key! We need the eyes (and possibly the hands)  of the
> > >> subject
> > matter experts, reviewing, commenting and possible fixing submissions.
> > >>
> > >>> it can be merged.  The approval is done via the
> > >>> GitHub approval system.
> > >> +1
> > >>> A commiter may create a PR on behalf of a patch submitted to the
> > mailing
> > >>> list.
> > >> +1
> > >>> Commiters can ask for others to review or approve.  But at the end
> > >>> of
> > the
> > >>> day they are the ones who approve and merge.
> > >> +1
> > >>> We can and should amend this later, it is likely not enough long
> term.
> > >>>
> > >>> Could people vote if they think this is fine to start. If you don't
> > agree
> > >>> just note that and we can review where we are at.
> > >>>
> > >>> --Brennan
> > >>>
> >
> >
>

Re: Simple Workflow Proposal

[Alin Jerpelea]

@David - sorry! you are right!


On Mon, Dec 23, 2019, 10:46 David Sidrane  wrote:

> +1 100% agreement
>
> WOW - The Evolve Way of Working (WoW) process (Disciplined Agile (DA))
>
> Please, Please do not assume TLA[1] are known.
>
> We do not all spec the same language here.
>
>
> -Original Message-
> From: Alin Jerpelea [mailto:jerpe...@gmail.com]
> Sent: Monday, December 23, 2019 12:41 AM
> To: dev@nuttx.apache.org
> Subject: Re: Simple Workflow Proposal
>
> If we want things to move we need an initial workflow or we risk to be
> stuck for weeks debating for a way forward.
> This simple workflow should move us forward so that we can improve it over
> several iterations.
> There are many new things for all of us and no WOW is tested and known to
> be our WOW. We must try new things to be able to move forward in the new
> structure.
>
>
> On Sun, Dec 22, 2019, 18:08 Brennan Ashton 
> wrote:
>
> > I did not call for a vote because I did not think I could as I'm just a
> > community member, I would like my proposal formally voted it on as is.
> >
> >
> > As for the two concerns that I saw raised.
> >
> > 1) The timeline. Two weeks over the holiday to come to a formal agreement
> > is going to be tough and I also don't think just because we have a path
> > forward people will stop caring about proposing a better solution.  From
> > what I'm seeing the longer term proposal will likely get into the weeds
> of
> > tooling around CI email patches etc... These take weeks to settle on. I
> > trust the intentions of the people in the project and do not see a need
> to
> > bind them to a timeline to build this out.
> >
> > 2) Why cut corners.  Personally I don't see this as cutting corners I
> > think
> > this will in practice get us 90% of the way there and get us back into a
> > cadence of improving the software.  I trust the project members will use
> > judgement within the structure and will actively move the project along
> to
> > better structure.
> >
> >
> > Thanks,
> > Brennan
> >
> >
> > On Sun, Dec 22, 2019, 7:08 AM Gregory Nutt  wrote:
> >
> > > Again, is this a formal vote?  it is not clear to me.  Did someone in
> > > the PPMC call a vote?  There is not [VOTE] in the message title?
> > >
> > > Just  point of order which I do not know the answer too.  Brennan is
> not
> > > yet listed as a PPMC member or a as a committer (but he should be and,
> > > hopefully, will be). Can non-PPMC members calls votes that are binding
> > > on the PPMC? Just to be clear, I think that someone in the PPMC should
> > > call the vote with [VOTE] in the title so that is is clear if we are
> > > castubg a binding vote or not for something are not?  Or are we just
> > > agreeing in principle or not?
> > >
> > > Are these binding votes?  We need to clarify what is going on.
> > >
> > > I think we should stop the habit of using +1 just to indicate we agree
> > > with something and we need to enforce the use of [VOTE] in the title so
> > > that we know this is a binding vote.
> > >
> > > On 12/22/2019 7:57 AM, Xiang Xiao wrote:
> > > > +1.
> > > > It's impotant to let people start the contribution.
> > > > The committer could/should do more work to ensure the correction in
> > > > review process before the automation tool is ready.
> > > >
> > > > Thanks
> > > > Xiang
> > > >
> > > > On Sun, Dec 22, 2019 at 8:57 PM David Sidrane 
> > > wrote:
> > > >> This works!
> > > >>
> > > >> On 2019/12/22 02:05:56, Brennan Ashton 
> > > wrote:
> > > >>> I really want to let people to contribute (myself included) ASAP so
> > > >>> I
> > > was
> > > >>> to propose this as an option to get going and can be amended later.
> > > >>> I
> > > know
> > > >>> it does not resolve all the issues, but offers what I think is a
> > > reasonable
> > > >>> avenue to get started.
> > > >>>
> > > >>> Submit a PR on GitHub against master if it is approved by one
> > commiter
> > > >>> (that did not propose it)
> > > >> This is key! We need the eyes (and possibly the hands)  of the
> > > >> subject
> > > matter experts, reviewing, commenting and possible fixing submissions.
> > > >>
> > > >>> it can be merged.  The approval is done via the
> > > >>> GitHub approval system.
> > > >> +1
> > > >>> A commiter may create a PR on behalf of a patch submitted to the
> > > mailing
> > > >>> list.
> > > >> +1
> > > >>> Commiters can ask for others to review or approve.  But at the end
> > > >>> of
> > > the
> > > >>> day they are the ones who approve and merge.
> > > >> +1
> > > >>> We can and should amend this later, it is likely not enough long
> > term.
> > > >>>
> > > >>> Could people vote if they think this is fine to start. If you don't
> > > agree
> > > >>> just note that and we can review where we are at.
> > > >>>
> > > >>> --Brennan
> > > >>>
> > >
> > >
> >
>

Re: [DISCUSS] Simple Workflow Proposal

[Justin Mclean]

Hi,

Apache has a concept of small reversible steps, if something can move the 
project forward, try it out, it it doesn’t work or you find a problem need just 
make another small step in the right direction.

Many many Apache projects use CTR (commit and review later) and have simple 
workflows and the sky doesn’t fall in and the code quality is still 
exceptional. While that doesn’t mean this project need to go down that path, 
perhaps however think about how likely the worse outcome is and how easily it 
will be to fix. You have many many eyes on the codebase, attracting more 
committers make that easier. Setting the committer bat too high or having a 
process that is too difficult to follow can stop committers from contributing 
and perhaps even kill the project. I can point to some examples, one in 
particular keep denying right to the end that "code quality” was more important 
than having committers until it reached a point where it had no active 
committers You primary concern should be to make it easy for people to get 
involved and grow the community.

I would also suggest you try to slow down the conversation here and think a 
little more about what you write, that way you get higher quality responses. 
There is much honour in the email not sent.

Thanks,
Justin

RE: [DISCUSS] Simple Workflow Proposal

[David Sidrane]

Well Said!

-Original Message-
From: Justin Mclean [mailto:jus...@classsoftware.com]
Sent: Monday, December 23, 2019 1:02 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] Simple Workflow Proposal

Hi,

Apache has a concept of small reversible steps, if something can move the
project forward, try it out, it it doesn’t work or you find a problem need
just make another small step in the right direction.

Many many Apache projects use CTR (commit and review later) and have simple
workflows and the sky doesn’t fall in and the code quality is still
exceptional. While that doesn’t mean this project need to go down that path,
perhaps however think about how likely the worse outcome is and how easily
it will be to fix. You have many many eyes on the codebase, attracting more
committers make that easier. Setting the committer bat too high or having a
process that is too difficult to follow can stop committers from
contributing and perhaps even kill the project. I can point to some
examples, one in particular keep denying right to the end that "code
 quality” was more important than having committers until it reached a point
where it had no active committers You primary concern should be to make it
easy for people to get involved and grow the community.

I would also suggest you try to slow down the conversation here and think a
little more about what you write, that way you get higher quality responses.
There is much honour in the email not sent.

Thanks,
Justin

Re: [DISCUSS] Simple Workflow Proposal

[Justin Mclean]

Hi,

> I would also suggest you try to slow down the conversation here and think a 
> little more about what you write, that way you get higher quality responses.

It’s also allows more timid people and those who are not full time on this to 
speak up and get noticed. Some ASF people make a self imposed rule (which I 
just broke) to only email a thread once a day.

Thanks,
Justin

Signal to Noise (was RE: [DISCUSS] Simple Workflow Proposal)

[David Sidrane]

Hi,

>-Original Message-
>From: Justin Mclean [mailto:jus...@classsoftware.com]
>Sent: Monday, December 23, 2019 1:09 AM
>To: dev@nuttx.apache.org
>Subject: Re: [DISCUSS] Simple Workflow Proposal

>Hi,

>> I would also suggest you try to slow down the conversation here and think
>> a little more about what you write, that way you get >higher quality
>> responses.

>It’s also allows more timid people and those who are not full time on this
>to speak up and get noticed. Some ASF people make a >self imposed rule
>(which I just broke) to only email a thread once a day.

>Thanks,
>Justin

Ok we both have no honor nor impulse control :)

I was thinking about calling a vote on limiting the # of emails. We have a
very gifted team. With that comes some strong instinctual desires for
exactness.

This really resonated with me when I first heard it.

Don't Let the Perfect Be the Enemy of the Good [1]

Voltaire: “The best is the enemy of the good.”
Confucius: "Better a diamond with a flaw than a pebble without."
Shakespeare: “Striving to better, oft we mar what's well.”

[1] https://www.entrepreneur.com/article/249676

Re: [PATCH] doubt about fwrite

[David Sidrane]

Hi wei peng
 See below.

On 2019/12/23 07:41:40, wei peng  wrote: 
> hi~
>   I connected the target board to terminal via "telnet" ,  in some cases
> the terminal will be frozen. Here are detailed steps:
> 
>1. Enable "CONFIG_IOB_DEBUG"[necessary].
>2. New two terminals and connect to target board via "telnet".
>3. Input "dmesg" command,and the terminal will show information
>*continuously*.[two terminals are same][necessary]
>4. Close one of  the terminals,and the other one will be frozen.but the
>system is work on.
> 
> I debug the system and repaired the bug,the file named commit.txt is
> detailed steps.
> BR,
> 
> wei peng

The interface is dictated by the OpenGroup stands [1]
[1] https://pubs.opengroup.org/onlinepubs/009695399/functions/fwrite.html

So that can not be changed.

There must be a root cause related to what you are doing or a bug in the 
system. Check the configuration (compare it to other telnet board configs). 

Are you Entering dmesg on both terminals or on one and it is showing up the 2 
terminals?

David

Re: Community

[David Sidrane]

On 2019/12/22 19:29:38, Gregory Nutt  wrote: 
> 
> > Don't feel bad if there is haggling. Any document, no matter who writes it
> > or how well, will need more work to fill in missing pieces, edit, etc., to
> > bring it to "shipping quality." I will try to help as much as I can in the
> > coming days, but as I said I'm really swamped right now.
> 
> But there are issues of trust related here.   I would not trust DavidS 
> to write objective work flow requirements now.  And I have no reason to 
> believe that he would trust me to do so either. Although I can say that 
> it would be my intention to produce a fair representation of the overall 
> discussion, my references would also be reflected in certain areas.
> 
> 
> 
Greg - please realize  that anything I (or you) suggest are just suggestion and 
examples. We are all going have to AGREE on what we will implement. Nothing bad 
is going to happen. None of it is in stone.

I would ask you to not couch thing in trust. It is not about trust. It is about 
experience.  You have created a wonderful gift to the world, in Nuttx. Using a 
"single commiter" model, a set of tools that you manage, and your own way of 
working.  You referred  to yourself as a Github  N00B. Other members on this 
team use github everyday. Their experience is what is of value here. I have not 
doubt that after you are a seasoned GH user of you would be able to craft the 
perfect GH work flow. 

My dad shared this with me once: If you can not dig a hole, do not stand over 
someone who is digging and tell them how to dig. Get the hell out of the way, 
let them do their job and bring them water.

Another pearl from him is: "You can't push a string"

Re: Community

[spudaneco]

It is too early to be digging holes.  Let's agree where the whole should be dug 
before we start digging.  Then there will be no one looking over your 
shoulder.Sent from Samsung tablet.
 Original message From: David Sidrane  
Date: 12/23/19  4:10 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: 
Community On 2019/12/22 19:29:38, Gregory Nutt  wrote: > > 
> Don't feel bad if there is haggling. Any document, no matter who writes it> > 
or how well, will need more work to fill in missing pieces, edit, etc., to> > 
bring it to "shipping quality." I will try to help as much as I can in the> > 
coming days, but as I said I'm really swamped right now.> > But there are 
issues of trust related here.   I would not trust DavidS > to write objective 
work flow requirements now.  And I have no reason to > believe that he would 
trust me to do so either. Although I can say that > it would be my intention to 
produce a fair representation of the overall > discussion, my references would 
also be reflected in certain areas.> > > Greg - please realize  that anything I 
(or you) suggest are just suggestion and examples. We are all going have to 
AGREE on what we will implement. Nothing bad is going to happen. None of it is 
in stone.I would ask you to not couch thing in trust. It is not about trust. It 
is about experience.  You have created a wonderful gift to the world, in Nuttx. 
Using a "single commiter" model, a set of tools that you manage, and your own 
way of working.  You referred  to yourself as a Github  N00B. Other members on 
this team use github everyday. Their experience is what is of value here. I 
have not doubt that after you are a seasoned GH user of you would be able to 
craft the perfect GH work flow. My dad shared this with me once: If you can not 
dig a hole, do not stand over someone who is digging and tell them how to dig. 
Get the hell out of the way, let them do their job and bring them water.Another 
pearl from him is: "You can't push a string"

[GitHub] [incubator-nuttx] davids5 commented on issue #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568445894
 
 
   > Maybe we can use git pre-commit hook to ensure anyone run nxsytle before 
commit to his/her local working branch:
   > https://eing.github.io/technology/2016/01/28/Git-Pre-Commit-Hooks-Part1/
   > And we even can run make in pre-commit.sh to generate the nxsytle.
   
   Yes. I had sent it on the list at one point, Not sure what list
   
   @xiaoxiang781216 - please consider [this 
issue](https://github.com/PX4/Firmware/issues/7125) and How it will effect us.
   
   .git/hooks/pre-commit
   ```
   #!/bin/sh
   #
   # Copyright (c) 2012 - 2019, PX4 Development Team
   # All rights reserved.
   #
   # Redistribution and use in source and binary forms, with or without
   # modification, are permitted provided that the following conditions are met:
   #
   # * Redistributions of source code must retain the above copyright notice, 
this
   #  list of conditions and the following disclaimer.
   # 
   # * Redistributions in binary form must reproduce the above copyright notice,
   #  this list of conditions and the following disclaimer in the documentation
   #   and/or other materials provided with the distribution.
   # 
   # * Neither the name of the copyright holder nor the names of its
   #   contributors may be used to endorse or promote products derived from
   #  this software without specific prior written permission.
   # 
   # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
   # AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
   # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
ARE
   # DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE 
LIABLE
   # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
   # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
   # SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
   # CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
LIABILITY,
   # OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE 
USE
   # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
   # 
   #
   # An example hook script to verify what is about to be committed.
   # Called by "git commit" with no arguments.  The hook should
   # # exit with non-zero status after issuing an appropriate message if
   # it wants to stop the commit.
   #
   # To enable this hook, rename this file to "pre-commit".
   
   if git rev-parse --verify HEAD >/dev/null 2>&1
   then
against=HEAD
   else
# Initial commit: diff against an empty tree object
against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
   fi
   
   # If you want to allow non-ascii filenames set this variable to true.
   allownonascii=$(git config hooks.allownonascii)
   
   # Redirect output to stderr.
   exec 1>&2
   
   # Cross platform projects tend to avoid non-ascii filenames; prevent
   # them from being added to the repository. We exploit the fact that the
   # printable range starts at the space character and ends with tilde.
   if [ "$allownonascii" != "true" ] &&
# Note that the use of brackets around a tr range is ok here, (it's
# even required, for portability to Solaris 10's /usr/bin/tr), since
# the square bracket bytes happen to fall in the designated range.
test $(git diff --cached --name-only --diff-filter=A -z $against |
  LC_ALL=C tr -d '[ -~]\0' | wc -c) != 0
   then
echo "Error: Attempt to add a non-ascii file name."
echo
echo "This can cause problems if you want to work"
echo "with people on other platforms."
echo
echo "To be portable it is advisable to rename the file ..."
echo
echo "If you know what you are doing you can disable this"
echo "check using:"
echo
echo "  git config hooks.allownonascii true"
echo
exit 1
   fi
   
   # If there are whitespace errors, print the offending file names and fail.
   git diff-index --check --cached $against --
   if [ $? -ne 0 ]
   then
   exit 1
   fi
   
   # Check for code style, only in changed files
   for i in `git diff --cached --name-only --diff-filter=ACM`
   do
echo $i:
   FILENAME=$(basename $i)
   FILE_EXT="${FILENAME#*.}"
echo FILENAME=$FILENAME
echo FILE_EXT=$FILE_EXT
   if [ "$FILE_EXT" = "c" ] || [ "$FILE_EXT" = "h" ]; then
./tools/nxstyle -m 80 $i 
fi
echo 
   done
   exec < /dev/tty
   while true; do
read -p "[post-commit hook] Commit? (Y/n) " yn
if [ "$yn" = "" ]; then
   yn='Y'
fi
case $yn in
  [Yy] ) exit 0; break;;
  [Nn] ) exit 1;;
  * ) echo "Please answer y or n for yes or 

[GitHub] [incubator-nuttx] davids5 commented on issue #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568446656
 
 
   Oh I should also mention that the this was from before I added the class of 
error and treated long lines as warnings in H files.
   
   ```
   exec < /dev/tty
   while true; do
read -p "[post-commit hook] Commit? (Y/n) " yn
if [ "$yn" = "" ]; then
   yn='Y'
fi
case $yn in
  [Yy] ) exit 0; break;;
  [Nn] ) exit 1;;
  * ) echo "Please answer y or n for yes or no.";;
  esac
done
   ```
   
   Is not the way this should work it is Just that nxstyle is not mature enough 
to trust.


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] davids5 commented on issue #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568456453
 
 
   > @btashton @davids5 What I mean here is that we don't need modify Makefile, 
is engouh to add a script invoke nxstyle(maybe build it too) to check the style 
for specific file/files or commit/commits.
   > Then we instruct people integrate this script into pre-commit hook to 
enable the check automatically. Like:
   > https://github.com/torvalds/linux/blob/master/scripts/checkpatch.pl
   > Nobody try to integrate checkpatch.pl into Linux build system, since 
developer can run checkpatch.pl directly to:
   > 1.The bunch of specified files
   > 2.The bunch of specified commits
   > 3.The current living change
   > 4.Integrate to pre-commit hook
   
   > nxstyle(maybe build it too) 
   
   That is make's job.
   
   > It's much flexible than make check_format since we can pass the different 
argument to script form command line, but the same thing is hard to do for 
Makefile.
   
   I agree - but adding it to the make file has some benefits and it does not 
prevent any entity (user, ci, tools) from running the script directly.
   
   There are a few subtle points here from a non-power users and system POV. 
   
   We want to grow the community it is make for easy of use fot N00Bs
   
   1.  Most editors and ide's have make integration. 
   2.  First normal form and abstraction.

   If we add the formatting targets to the `MakeFile` it is top down and 
use-able by the users, CI and other tools.
   
   `make check_format`
   `make check _format_all`
   and for the user (When, we have a decent tool)  
   `make format` - that fixes the issues
   
   As of today `nxstyle` lives in `tools` and in tree.  It may need to be 
moved. Think about the best practices with git when the release branch's 
nxstyle != master's nxstyle and master is correct nxstye (or a conf file for a 
real tool).  
   
   It will level room for a whole class of errors we can avoid with a simple 
Workflow.  
   
   Also consider the change to tools like when nxstyle++ is written or we use 
clang-format. Do you want to update the location and process everywhere: in the 
CI repos, containers and  ./tools or do you want to update the makefile? 
   
   @btashton , @xiaoxiang781216  Please set me straight if I am off course or 
too myopic.  
   The things we get wrong now will become technical-debt. Granted at this 
point it in time it is small but when there are 300 committers on nuttx it will 
be a problem 300 times lager.


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] davids5 commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on a change in pull request #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360866861
 
 

 ##
 File path: tools/Makefile.unix
 ##
 @@ -697,3 +704,8 @@ apps_distclean:
 ifneq ($(APPDIR),)
$(Q) $(MAKE) -C "$(TOPDIR)/$(APPDIR)" TOPDIR="$(TOPDIR)" distclean
 endif
+
+check_format:
+   $(call colorecho,'Checking NuttX formatting with nxstyle')
 
 Review comment:
   ```
   # This is a top-level "kludge" Makefile that just includes the correct
   # Makefile.  If you already know the Makefile that you want, you can skip
   # this nonsense using:
   #
   #   make -f Makefile.unix, OR
   #   make -f Makefile.win
   #
   
   -include .config
   ifeq ($(CONFIG_WINDOWS_NATIVE),y)
   include tools/Makefile.win
   else
   include tools/Makefile.unix
   endif
   ```
   
   @patacongo Here?


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] patacongo commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

patacongo commented on a change in pull request #2: Master pr nxstyle 
improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360730399
 
 

 ##
 File path: tools/Makefile.unix
 ##
 @@ -697,3 +704,8 @@ apps_distclean:
 ifneq ($(APPDIR),)
$(Q) $(MAKE) -C "$(TOPDIR)/$(APPDIR)" TOPDIR="$(TOPDIR)" distclean
 endif
+
+check_format:
+   $(call colorecho,'Checking NuttX formatting with nxstyle')
 
 Review comment:
   Description of all new make targets should be included in the top-level 
README, including a description of what the make target does.


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] patacongo commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

patacongo commented on a change in pull request #2: Master pr nxstyle 
improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360868178
 
 

 ##
 File path: tools/Makefile.unix
 ##
 @@ -697,3 +704,8 @@ apps_distclean:
 ifneq ($(APPDIR),)
$(Q) $(MAKE) -C "$(TOPDIR)/$(APPDIR)" TOPDIR="$(TOPDIR)" distclean
 endif
+
+check_format:
+   $(call colorecho,'Checking NuttX formatting with nxstyle')
 
 Review comment:
   No, I meant README not Makefile.  Here:
   
   `1354 Build Targets and Options`


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: Signal to Noise (was RE: [DISCUSS] Simple Workflow Proposal)

[Justin Mclean]

Hi,

> I was thinking about calling a vote on limiting the # of emails.

IMO A vote will not help, it will make things worse, perhaps try discuss but 
most of all just try to be a little more considerate for people who are 
subscribers to this list. No hard rules just guidelines and consideration of 
your users. Not everything needs a vote. That being said, let'd be clear that's 
just my opinion and carries no more weight than any other person here. (I’m not 
wearing my mentor, IPMC or VP Incubator hat unless I explicitly state otherwise 
and that is very rare).

There’s a Spark talk that might help here (by Holden Karau) on the firehose 
that is their mailing list and PRs they get, I see if I can find the talk. Just 
be aware, that for a number of reasons, what Spark does may not be the best 
model to follow for an incubating project but it may give some insight all the 
same.

Thanks,
Justin

[GitHub] [incubator-nuttx] jarivanewijk commented on issue #1: imxrt fixes

[GitBox]

jarivanewijk commented on issue #1: imxrt fixes 
URL: https://github.com/apache/incubator-nuttx/pull/1#issuecomment-568463453
 
 
   Thank you for your work, @davids5!
   
   > We should warn all the NXP IMXRT and I think NXP S32K users the code will 
hang the OS.
   
A lot of the peripheral code for S32K seems to be taken from i.MX RT, so it 
is probably affected by this is as well. There are probably not many S32K users 
yet, though. We are working at NXP to improve the support for the S32K1xx and 
their evaluation boards. The progress is slow but steady. After the holidays I 
will apply your fixes to S32K on our internal NuttX fork. We will open a PR 
here eventually. (January/February?) 
   


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] jarivanewijk edited a comment on issue #1: imxrt fixes

[GitBox]

jarivanewijk edited a comment on issue #1: imxrt fixes 
URL: https://github.com/apache/incubator-nuttx/pull/1#issuecomment-568463453
 
 
   Thank you for your work, @davids5!
   
   > We should warn all the NXP IMXRT and I think NXP S32K users the code will 
hang the OS.
   
A lot of the peripheral code for S32K seems to be taken from i.MX RT, so it 
is likely affected by this is as well. There are probably not many S32K users 
yet, though. We are working at NXP to improve the support for the S32K1xx and 
their evaluation boards. The progress is slow but steady. After the holidays I 
will apply your fixes to S32K on our internal NuttX fork. We will open a PR 
here eventually. (January/February?) 
   


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] jarivanewijk edited a comment on issue #1: imxrt fixes

[GitBox]

jarivanewijk edited a comment on issue #1: imxrt fixes 
URL: https://github.com/apache/incubator-nuttx/pull/1#issuecomment-568463453
 
 
   Thank you for your work, @davids5!
   
   > We should warn all the NXP IMXRT and I think NXP S32K users the code will 
hang the OS.
   
A lot of the peripheral code for S32K seems to be taken from i.MX RT, so it 
is likely affected by this is as well. There are probably not many S32K users 
yet, though. We are working at NXP to improve the support for the S32K1xx and 
their evaluation boards. The progress is slow but steady. After the holidays I 
will apply your fixes to S32K on our internal NuttX repository. We will open a 
PR here eventually. (January/February?) 
   


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: [DISCUSS] Simple Workflow Proposal

[Duo Zhang]

For our Chinese people we do not think starting working when the
requirements are not very clear is a big risk, this is what happens every
day here. You can not plan everything so just have a try, if it does not
work then just drop it and retry, no harm :)

And in my experience, if we can not agree on something, and seems the
direction of the conversation is not going to solve the problem, then we
should stop, and try to make consensus on something else, maybe on a higher
level, or a precondition of the current problem. If we can not even make a
consensus then we do not need to talk any more, honestly.

And back to the discussion here, I think we all agree that, we want the
NuttX project to be successful right? Everyone here just wants to help,
let’s be friendly to each other.

And second, what is the most emergency problem for now? I do not think it
is the workflow. We can not accept new patches, this is the biggest problem
I think. And since it is Christmas so as Greg said maybe we can delay it
for two weeks, but anyway it will still be the biggest problem after we
come back from Christmas(OK I need to say that we Chinese people do not
have Christmas holidays...).

Do we really need a new workflow for accepting patches? I do not think so,
now the only difference is that the code has been moved from bitbucket to
github, so follow the old workflow is an option I’d say. Let’s do things
step by step.

Anyway, I think we should make a consensus first, if we all agree that
accepting new patches is the most emergency problem for now, then we can
start to talk the further actions. If not, let’s first define the problem.
We really need to start from a consensus.

My two cents. Thanks.

Gregory Nutt 于2019年12月23日 周一10:02写道：

>
> > But the #1 most critical thing facing this project is adopting even
> > just the requirements for the workflow.  None of the other issues have
> > any significant importance
> >
> > So I have to be opposed to any obstacles that jeopardize or distract
> > from the #1 priority thing.
>
> One of the dangers of delaying the workflow requirements is that there
> are people actually developing workflow components now ... WITHOUT any
> requirements!!! Pull unadulterated rogue behavior. There is a great risk
> of just have some workflow foisted upon us with no ability by the PPMC
> to guide or monitor.
>
> We will be giving away our right to define the workflow it we do not
> make progress on the workflow requirements.  Yet another rogue workflow
> will be forced on us.
>
> I think we must decline any attempts to do commit unapproved workflow
> components.  We must not allow any workflow to be put into place without
> the concurrence of the PPMC.  We give our concurrence only by agreeing
> to a set of workflow requirements then enforcing those requirements.
>
> Greg
>
>
>

RE: [DISCUSS] Simple Workflow Proposal

[David Sidrane]

Hi Duo,

Well said and I am all for it.

Two questions:

1 Who will apply the patches?
2 Can we use and merge a PR that has been reviewed?

David


-Original Message-
From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com]
Sent: Monday, December 23, 2019 4:35 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] Simple Workflow Proposal

For our Chinese people we do not think starting working when the
requirements are not very clear is a big risk, this is what happens every
day here. You can not plan everything so just have a try, if it does not
work then just drop it and retry, no harm :)

And in my experience, if we can not agree on something, and seems the
direction of the conversation is not going to solve the problem, then we
should stop, and try to make consensus on something else, maybe on a higher
level, or a precondition of the current problem. If we can not even make a
consensus then we do not need to talk any more, honestly.

And back to the discussion here, I think we all agree that, we want the
NuttX project to be successful right? Everyone here just wants to help,
let’s be friendly to each other.

And second, what is the most emergency problem for now? I do not think it
is the workflow. We can not accept new patches, this is the biggest problem
I think. And since it is Christmas so as Greg said maybe we can delay it
for two weeks, but anyway it will still be the biggest problem after we
come back from Christmas(OK I need to say that we Chinese people do not
have Christmas holidays...).

Do we really need a new workflow for accepting patches? I do not think so,
now the only difference is that the code has been moved from bitbucket to
github, so follow the old workflow is an option I’d say. Let’s do things
step by step.

Anyway, I think we should make a consensus first, if we all agree that
accepting new patches is the most emergency problem for now, then we can
start to talk the further actions. If not, let’s first define the problem.
We really need to start from a consensus.

My two cents. Thanks.

Gregory Nutt 于2019年12月23日 周一10:02写道：

>
> > But the #1 most critical thing facing this project is adopting even
> > just the requirements for the workflow.  None of the other issues have
> > any significant importance
> >
> > So I have to be opposed to any obstacles that jeopardize or distract
> > from the #1 priority thing.
>
> One of the dangers of delaying the workflow requirements is that there
> are people actually developing workflow components now ... WITHOUT any
> requirements!!! Pull unadulterated rogue behavior. There is a great risk
> of just have some workflow foisted upon us with no ability by the PPMC
> to guide or monitor.
>
> We will be giving away our right to define the workflow it we do not
> make progress on the workflow requirements.  Yet another rogue workflow
> will be forced on us.
>
> I think we must decline any attempts to do commit unapproved workflow
> components.  We must not allow any workflow to be put into place without
> the concurrence of the PPMC.  We give our concurrence only by agreeing
> to a set of workflow requirements then enforcing those requirements.
>
> Greg
>
>
>

[GitHub] [incubator-nuttx] davids5 commented on issue #1: imxrt fixes

[GitBox]

davids5 commented on issue #1: imxrt fixes 
URL: https://github.com/apache/incubator-nuttx/pull/1#issuecomment-568469970
 
 
   > Thank you for your work, @davids5!
   > 
   > > We should warn all the NXP IMXRT and I think NXP S32K users the code 
will hang the OS.
   > 
   > A lot of the peripheral code for S32K seems to be taken from i.MX RT, so 
it is likely affected by this is as well. There are probably not many S32K 
users yet, though. We are working at NXP to improve the support for the S32K1xx 
and their evaluation boards. The progress is slow but steady. After the 
holidays I will apply your fixes to S32K on our internal NuttX repository. We 
will open a PR here eventually. (January/February?)
   
   @jarivanewijk - yes exactly.  It was cloned by @patacongo before I had the 
RDDRONE-FMURT6 HW to validate it on.  It may be marked EXPERIMENTAL , but I 
have not followed it's progress. 
   
   I will ask @igalloway for HW and I can cross check locally as well.  


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] davids5 commented on issue #1: imxrt fixes

[GitBox]

davids5 commented on issue #1: imxrt fixes 
URL: https://github.com/apache/incubator-nuttx/pull/1#issuecomment-568473865
 
 
   @btashton 
   
   > @davids5 This touches some of the same IO stuff that I have been working 
on on the imxrt platform, some of the changes are style. Did you make these 
changes via one of the existing tools, or was this manual. I want to make sure 
my changes apply cleanly on top of this. For now I will carry this in my tree.
   
   yeah - we really should talk this through. I had a very detailed discussion 
on yahoo on what we had learns from the STM32 night organic-lay grown 
nightmare.  
   
   The gist of it is: There are clear patterns that should be use when there is 
a chip family.
   
   @mubes make some great strides in this on the RT, but took some shortcuts 
when the imxrt20 came in. We should **not** follow that pattern.
   
   All the gpio tables need to broken out and the included like the clockconfig 
does STM32 or the dasiy does n the imxrt. 
   
   #ifddef rash has to be avoided or kept to a minimum.  It use to be before 
the 20 commit. 
   Scope has to be be maintained.
   
   Let' plan a call then bring it back to the list.


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] davids5 edited a comment on issue #1: imxrt fixes

[GitBox]

davids5 edited a comment on issue #1: imxrt fixes 
URL: https://github.com/apache/incubator-nuttx/pull/1#issuecomment-568473865
 
 
   @btashton 
   
   > @davids5 This touches some of the same IO stuff that I have been working 
on on the imxrt platform, some of the changes are style. Did you make these 
changes via one of the existing tools, or was this manual. I want to make sure 
my changes apply cleanly on top of this. For now I will carry this in my tree.
   
   yeah - we really should talk this through. I had a very detailed discussion 
on yahoo on what we had learned from the STM32  organically grown nightmare.  
   
   The gist of it is: There are clear patterns that should be use when there is 
a chip family.
   
   @mubes make some great strides in this on the RT, but took some shortcuts 
when the imxrt20 came in. We should **not** follow that pattern.
   
   All the gpio tables need to broken out and the included like the clockconfig 
does STM32 or the dasiy does n the imxrt. 
   
   #ifddef rash has to be avoided or kept to a minimum.  It use to be before 
the 20 commit. 
   Scope has to be be maintained.
   
   Let' plan a call then bring it back to the list.


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] davids5 commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on a change in pull request #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360886136
 
 

 ##
 File path: tools/check_code_style.sh
 ##
 @@ -0,0 +1,33 @@
+#!/usr/bin/env bash
+
+if [ -z "$1" ]; then
+   FILES=$(git diff master --name-only);
 
 Review comment:
   > Similar problem here. You must check if .git/ exists. If it does not, you 
may not use any git commands. Most users do not have .git/ and this will break 
for the majority of users.
   
   Done.


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] davids5 commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on a change in pull request #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360886392
 
 

 ##
 File path: tools/check_code_style.sh
 ##
 @@ -0,0 +1,33 @@
+#!/usr/bin/env bash
+
+if [ -z "$1" ]; then
+   FILES=$(git diff master --name-only);
+else
+   FILES=$1
+fi
+
+DIR=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )
+for FILE in $FILES; do
+  FILENAME=$(basename $FILE)
+  FILE_EXT="${FILENAME#*.}"
+  if [ -f "$FILE" ]; then
+if [ "$FILE_EXT" = "c" ] || [ "$FILE_EXT" = "h" ]; then
+ CHECK_FAILED=$(${DIR}/nxstyle $FILE)
+   #   if [ -n "$CHECK_FAILED" ]; then
+   #   ${DIR}/fix_code_style.sh --quiet < $FILE > $FILE.pretty
+   #
+   #   echo
+   #   git --no-pager diff --no-index --minimal --histogram 
--color=always $FILE $FILE.pretty
+   #   rm -f $FILE.pretty
 
 Review comment:
   Done


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] davids5 commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on a change in pull request #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360886535
 
 

 ##
 File path: tools/Makefile.unix
 ##
 @@ -697,3 +704,8 @@ apps_distclean:
 ifneq ($(APPDIR),)
$(Q) $(MAKE) -C "$(TOPDIR)/$(APPDIR)" TOPDIR="$(TOPDIR)" distclean
 endif
+
+check_format:
+   $(call colorecho,'Checking NuttX formatting with nxstyle')
 
 Review comment:
   Ah! Ok Wild do


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: [DISCUSS] Simple Workflow Proposal

[Duo Zhang]

Let's not start new questions for now? Be patient and let's see what other
people think. One of the most important rule in ASF is 'community over
code', so although I also think accepting patches is the most emergency
thing here, but let's see other people's opinion first.

Thanks.

David Sidrane  于2019年12月23日周一 下午8:58写道：

> Hi Duo,
>
> Well said and I am all for it.
>
> Two questions:
>
> 1 Who will apply the patches?
> 2 Can we use and merge a PR that has been reviewed?
>
> David
>
>
> -Original Message-
> From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com]
> Sent: Monday, December 23, 2019 4:35 AM
> To: dev@nuttx.apache.org
> Subject: Re: [DISCUSS] Simple Workflow Proposal
>
> For our Chinese people we do not think starting working when the
> requirements are not very clear is a big risk, this is what happens every
> day here. You can not plan everything so just have a try, if it does not
> work then just drop it and retry, no harm :)
>
> And in my experience, if we can not agree on something, and seems the
> direction of the conversation is not going to solve the problem, then we
> should stop, and try to make consensus on something else, maybe on a higher
> level, or a precondition of the current problem. If we can not even make a
> consensus then we do not need to talk any more, honestly.
>
> And back to the discussion here, I think we all agree that, we want the
> NuttX project to be successful right? Everyone here just wants to help,
> let’s be friendly to each other.
>
> And second, what is the most emergency problem for now? I do not think it
> is the workflow. We can not accept new patches, this is the biggest problem
> I think. And since it is Christmas so as Greg said maybe we can delay it
> for two weeks, but anyway it will still be the biggest problem after we
> come back from Christmas(OK I need to say that we Chinese people do not
> have Christmas holidays...).
>
> Do we really need a new workflow for accepting patches? I do not think so,
> now the only difference is that the code has been moved from bitbucket to
> github, so follow the old workflow is an option I’d say. Let’s do things
> step by step.
>
> Anyway, I think we should make a consensus first, if we all agree that
> accepting new patches is the most emergency problem for now, then we can
> start to talk the further actions. If not, let’s first define the problem.
> We really need to start from a consensus.
>
> My two cents. Thanks.
>
> Gregory Nutt 于2019年12月23日 周一10:02写道：
>
> >
> > > But the #1 most critical thing facing this project is adopting even
> > > just the requirements for the workflow.  None of the other issues have
> > > any significant importance
> > >
> > > So I have to be opposed to any obstacles that jeopardize or distract
> > > from the #1 priority thing.
> >
> > One of the dangers of delaying the workflow requirements is that there
> > are people actually developing workflow components now ... WITHOUT any
> > requirements!!! Pull unadulterated rogue behavior. There is a great risk
> > of just have some workflow foisted upon us with no ability by the PPMC
> > to guide or monitor.
> >
> > We will be giving away our right to define the workflow it we do not
> > make progress on the workflow requirements.  Yet another rogue workflow
> > will be forced on us.
> >
> > I think we must decline any attempts to do commit unapproved workflow
> > components.  We must not allow any workflow to be put into place without
> > the concurrence of the PPMC.  We give our concurrence only by agreeing
> > to a set of workflow requirements then enforcing those requirements.
> >
> > Greg
> >
> >
> >
>

[GitHub] [incubator-nuttx] patacongo commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

patacongo commented on a change in pull request #2: Master pr nxstyle 
improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360887055
 
 

 ##
 File path: tools/Makefile.unix
 ##
 @@ -324,6 +324,14 @@ tools/cnvwindeps$(HOSTEXEEXT):
 #  $(Q) echo "No .config file found, creating one"
 #  $(Q) tools/initialconfig$(HOSTEXEEXT)
 
+# make it easy to see what is happening
+COLOR_BLUE = \033[0;94m
 
 Review comment:
   There is no coding standard governing Makefiles.  Other locations in this 
file do put spaces after comments, just like the C requirement.


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] patacongo commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

patacongo commented on a change in pull request #2: Master pr nxstyle 
improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360887345
 
 

 ##
 File path: tools/check_code_style.sh
 ##
 @@ -0,0 +1,33 @@
+#!/usr/bin/env bash
+
+if [ -z "$1" ]; then
+   FILES=$(git diff master --name-only);
 
 Review comment:
   With no workflow requirements it is not safe to assume anything.


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] davids5 commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on a change in pull request #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360887522
 
 

 ##
 File path: tools/Makefile.unix
 ##
 @@ -324,6 +324,14 @@ tools/cnvwindeps$(HOSTEXEEXT):
 #  $(Q) echo "No .config file found, creating one"
 #  $(Q) tools/initialconfig$(HOSTEXEEXT)
 
+# make it easy to see what is happening
+COLOR_BLUE = \033[0;94m
 
 Review comment:
   ```suggestion
   
   COLOR_BLUE = \033[0;94m
   ```


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] davids5 commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on a change in pull request #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360889472
 
 

 ##
 File path: tools/Makefile.unix
 ##
 @@ -324,6 +324,14 @@ tools/cnvwindeps$(HOSTEXEEXT):
 #  $(Q) echo "No .config file found, creating one"
 #  $(Q) tools/initialconfig$(HOSTEXEEXT)
 
+# make it easy to see what is happening
+COLOR_BLUE = \033[0;94m
 
 Review comment:
   Done. Yes there seems to be the "what you do" and what we have documented - 
disconnect.
   # Please use the "Suggested Change Button or ctr-g" 


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] patacongo commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

patacongo commented on a change in pull request #2: Master pr nxstyle 
improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360898824
 
 

 ##
 File path: README.txt
 ##
 @@ -1368,6 +1368,15 @@ Build Targets and Options
 Removes derived object files, archives, executables, and temporary
 files, but retains the configuration and context files and directories.
 
+  check_format
+
+Will run nxstyle to check compliance with the NuttX coding standard on
+the files the have been changed relative to master.  This feature is only
+available if 1) git is installed and 2) the changed files are located in
+the local git repository and have been committed. The benefit of this
+flow is that commits that only effect formatting changes do not over
+shadow code changes. As of this writting this is a Uinx only feature.
+
 
 Review comment:
   Uinx->Unix


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: [DISCUSS] Simple Workflow Proposal

[Gregory Nutt]

Two questions:

1 Who will apply the patches?
2 Can we use and merge a PR that has been reviewed?

You are basically asking for the workflow requirements.

[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

xiaoxiang781216 commented on a change in pull request #2: Master pr nxstyle 
improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360904297
 
 

 ##
 File path: tools/Makefile.unix
 ##
 @@ -324,6 +324,14 @@ tools/cnvwindeps$(HOSTEXEEXT):
 #  $(Q) echo "No .config file found, creating one"
 #  $(Q) tools/initialconfig$(HOSTEXEEXT)
 
+# make it easy to see what is happening
+COLOR_BLUE = \033[0;94m
 
 Review comment:
   @davids5 I would prefer we work on check_code_style.sh first, and forget 
Makefile.unix at all.
   Why? this avoid we couple the script logic with Makefle, for example:
   1.The above implementation make the standalone script can't colorize the 
output.
   2.The dependence rule can't work if user invoke the script from shell 
directly.
   The best aproach is that we focus on the script development and make it work 
from command line as we want, then we can integrate the script either as the 
make target or precommit hook. Otherwise, the script will do a major rework for 
the standalone case.
   Invoking the script from command line is the key feature for this tool, 
becasue we need integrate this tool the various workflow(e.g. Makefile, 
precommit hook, jenkins job).


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 a change in pull request #2: Master pr nxstyle improvments

[GitBox]

xiaoxiang781216 commented on a change in pull request #2: Master pr nxstyle 
improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360904297
 
 

 ##
 File path: tools/Makefile.unix
 ##
 @@ -324,6 +324,14 @@ tools/cnvwindeps$(HOSTEXEEXT):
 #  $(Q) echo "No .config file found, creating one"
 #  $(Q) tools/initialconfig$(HOSTEXEEXT)
 
+# make it easy to see what is happening
+COLOR_BLUE = \033[0;94m
 
 Review comment:
   @davids5 I would prefer we work on check_code_style.sh first, and forget 
Makefile.unix at all.
   Why? this avoid we couple the script logic with Makefle, for example:
   1.The above implementation make the standalone script can't colorize the 
output.
   2.The dependence rule can't work if user invoke the script from shell 
directly.
   The best aproach is that we focus on the script development and make it work 
from command line as we want, then we can integrate the script either as the 
make target or precommit hook. Otherwise, the script will do a major rework for 
the standalone case.
   Invoking the script from command line is the key feature for this tool, 
becasue we need integrate this tool into various workflow(e.g. Makefile, 
precommit hook, jenkins job).


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] patacongo commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

patacongo commented on a change in pull request #2: Master pr nxstyle 
improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360905760
 
 

 ##
 File path: tools/Makefile.unix
 ##
 @@ -324,6 +324,14 @@ tools/cnvwindeps$(HOSTEXEEXT):
 #  $(Q) echo "No .config file found, creating one"
 #  $(Q) tools/initialconfig$(HOSTEXEEXT)
 
+# make it easy to see what is happening
+COLOR_BLUE = \033[0;94m
 
 Review comment:
   That actually makes a lot of sense, is simpler, and sounds more flexible.  I 
would tend to support Xiao Xiangs argument.


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] patacongo commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

patacongo commented on a change in pull request #2: Master pr nxstyle 
improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360905760
 
 

 ##
 File path: tools/Makefile.unix
 ##
 @@ -324,6 +324,14 @@ tools/cnvwindeps$(HOSTEXEEXT):
 #  $(Q) echo "No .config file found, creating one"
 #  $(Q) tools/initialconfig$(HOSTEXEEXT)
 
+# make it easy to see what is happening
+COLOR_BLUE = \033[0;94m
 
 Review comment:
   That actually makes a lot of sense, is simpler, and sounds more flexible.  I 
would tend to support Xiao Xiang's argument.


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] patacongo commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

patacongo commented on a change in pull request #2: Master pr nxstyle 
improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360905760
 
 

 ##
 File path: tools/Makefile.unix
 ##
 @@ -324,6 +324,14 @@ tools/cnvwindeps$(HOSTEXEEXT):
 #  $(Q) echo "No .config file found, creating one"
 #  $(Q) tools/initialconfig$(HOSTEXEEXT)
 
+# make it easy to see what is happening
+COLOR_BLUE = \033[0;94m
 
 Review comment:
   That actually makes a lot of sense, is simpler, and sounds more flexible.  I 
would tend to support Xiao Xiang's argument.
   
   Since this has taken a different twist, should we unresolve the conversation?


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] patacongo commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

patacongo commented on a change in pull request #2: Master pr nxstyle 
improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360917765
 
 

 ##
 File path: tools/Makefile.unix
 ##
 @@ -324,6 +324,14 @@ tools/cnvwindeps$(HOSTEXEEXT):
 #  $(Q) echo "No .config file found, creating one"
 #  $(Q) tools/initialconfig$(HOSTEXEEXT)
 
+# make it easy to see what is happening
+COLOR_BLUE = \033[0;94m
 
 Review comment:
   Unresolved only because I think we need to address Xiao Xiang's 
recommendation in some fashion.


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] patacongo commented on a change in pull request #2: Master pr nxstyle improvments

[GitBox]

patacongo commented on a change in pull request #2: Master pr nxstyle 
improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#discussion_r360917765
 
 

 ##
 File path: tools/Makefile.unix
 ##
 @@ -324,6 +324,14 @@ tools/cnvwindeps$(HOSTEXEEXT):
 #  $(Q) echo "No .config file found, creating one"
 #  $(Q) tools/initialconfig$(HOSTEXEEXT)
 
+# make it easy to see what is happening
+COLOR_BLUE = \033[0;94m
 
 Review comment:
   Unresolved only because I think we need to address Xiao Xiang's 
recommendation in some fashion.  It would have been better if this were a 
separate comment.


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] davids5 commented on issue #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568502128
 
 
   
   >@davids5 I would prefer we work on check_code_style.sh first, and forget 
Makefile.unix at all.
   Why? this avoid we couple the script logic with Makefle, for example:
   1.The above implementation make the standalone script can't colorize the 
output.
   2.The dependence rule can't work if user invoke the script from shell 
directly.
   The best aproach is that we focus on the script development and make it work 
from command line as we want, then we can integrate the script either as the 
make target or precommit hook. Otherwise, the script will do a major rework for 
the standalone case.
   Invoking the script from command line is the key feature for this tool, 
becasue we need integrate this tool the various workflow(e.g. Makefile, 
precommit hook, jenkins job).
   
   @xiaoxiang781216 - This is now 2 simple so you can separate them and do as 
you think best. 
   
   Please just release something that can be used with eclipse and VSCODE - The 
old tool wasted way too much time.  In the mean time I will backport this to 
PX4 as [REJECTED]  to keep our users productive.


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 #2: Master pr nxstyle improvments

[GitBox]

xiaoxiang781216 commented on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568512309
 
 
   > > @btashton @davids5 What I mean here is that we don't need modify 
Makefile, is engouh to add a script invoke nxstyle(maybe build it too) to check 
the style for specific file/files or commit/commits.
   > > Then we instruct people integrate this script into pre-commit hook to 
enable the check automatically. Like:
   > > https://github.com/torvalds/linux/blob/master/scripts/checkpatch.pl
   > > Nobody try to integrate checkpatch.pl into Linux build system, since 
developer can run checkpatch.pl directly to:
   > > 1.The bunch of specified files
   > > 2.The bunch of specified commits
   > > 3.The current living change
   > > 4.Integrate to pre-commit hook
   > 
   > > nxstyle(maybe build it too)
   > 
   > That is make's job.
   > 
   
   Yes, but we already have the rule in tools/Makefile.host for generating 
nxstyle binary, the question is where should we trigger the target. It's better 
to let the script trigger the buildotherwise user can't invoke the tool outside 
the make environment(e.g. from jenkins job, precommit hook or command line).
   
   > > It's much flexible than make check_format since we can pass the 
different argument to script form command line, but the same thing is hard to 
do for Makefile.
   > 
   > I agree - but adding it to the make file has some benefits and it does not 
prevent any entity (user, ci, tools) from running the script directly.
   > 
   > There are a few subtle points here from a non-power users and system POV.
   > 
   > We want to grow the community it is make for easy of use fot N00Bs
   > 
   > 1. Most editors and ide's have make integration.
   > 2. First normal form and abstraction.
   > 
   > If we add the formatting targets to the `MakeFile` it is top down and 
use-able by the users, CI and other tools.
   > 
   > `make check_format`
   > `make check _format_all`
   > and for the user (When, we have a decent tool)
   > `make format` - that fixes the issues
   > 
   
   Sorry, I make some confusion here. The build target to check/fix the style 
issuse is good idea, but we need also consider other use case too(e.g. command 
line, precommit hook and jenkins job). So it's better to develop the script 
first and keep all invoking environment in mind and equally(don't bias on make 
too earily). Once the script is ready, the integrattion is a very simple task.
   
   > As of today `nxstyle` lives in `tools` and in tree. It may need to be 
moved. Think about the best practices with git when the release branch's 
nxstyle != master's nxstyle and master is correct nxstye (or a conf file for a 
real tool).
   > 
   > It will level room for a whole class of errors we can avoid with a simple 
Workflow.
   > 
   > Also consider the change to tools like when nxstyle++ is written or we use 
clang-format. Do you want to update the location and process everywhere: in the 
CI repos, containers and ./tools or do you want to update the makefile?
   
   Yes, I agree we need a shell script here, so we can change the implentation 
without influencing any user. But we shouldn't move the script to any other 
location: tools/ is a good place.
   
   > 
   > @btashton , @xiaoxiang781216 Please set me straight if I am off course or 
too myopic.
   > The things we get wrong now will become technical-debt. Granted at this 
point it in time it is small but when there are 300 committers on nuttx it will 
be a problem 300 times lager.
   
   


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: [DISCUSS] Simple Workflow Proposal - not so simple?

[Sebastien Lorquet]

OK.

That is too much email for me, I just cant follow and understand all these
discussions anymore. Almost 300 messages among multiple overlapping threads full
of heated opinions in 2-3 days is insane.

I just cant dedicate enough time reading any more of this. I have other things
to do than trying to understand these multiple rebooted workflows proposals that
span days (and nights!) of discussions.

So I can't vote on anything. I dont understand what is going on anymore. I'm
lost. Probably not important since I did not ask and choose to be a committer,
but since opinions are asked, here are mine.


Can someone please sum up what we have to decide in a short email, less than a 
page?


To be honest, viewed from here, I just seem to understand that some opinions are
very pushy and are trying to act before decisions are settled.

Also some kind of extra-heavy decisions on a full process NO ONE has been able
to install up to now for years.

I just want to say that going to apache should not be an occasion to try to
force the process of someone liking or another just because not everyone has an
equally stronger opinion and voice and free time for emails.

On my part, seeing too hard pushes in any specific direction just rings an alarm
bell to be extra-cautious.


I think the process should be as simple as possible, and improved later. Just
select the absolute bare minimum that could start to work and discard everything
else so this project can work again.


We are using git so things are reversable, right? We will not get this right the
first time, so lets keep room for errors. If I understand correctly the
bitbucket repositories are still in a consistent pre-apache state and the apache
ones can be reset? or is the apache->bb mirroring already active?

Also, I did not see a notification that the BB repositories had been frozen.


These workflow and reviewing discussions are just killing extremely valuable
time for everyone without visible progress (because too many messages).


So again, I would like to read a very short state of the union at monday
2019-Dec-23 17:01 UTC+1.

Otherwise I cant make decisions. And I guess I am not the only one.


Sebastien


Le 22/12/2019 à 17:25, Gregory Nutt a écrit :
>
>> Let's get everyone's thoughts on the table 
>
> I suppose that we should keep the discussion for 72 hours then call the vote. 
> We need to allow time for everyone to comment and with the holidays, we may
> not be able to get good feedback. Should we still call a vote if people are
> not participating?
>
> I will call the vote on your behalf in 72 hours.
>
> Greg
>
>
>

Re: [DISCUSS] Simple Workflow Proposal - not so simple?

[Gregory Nutt]

Agreed.. It is painful and awkward and I am not so optimistic at the 
moment.  We will have to give it more time and see if people and learn 
to cooperate in groups or not.

Also, I did not see a notification that the BB repositories had been frozen.


https://groups.google.com/forum/#!topic/nuttx/ISmgZAftm4o

[GitHub] [incubator-nuttx] davids5 commented on issue #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568525036
 
 
   >Yes, but we already have the rule in tools/Makefile.host for generating 
nxstyle binary, the question is where should we trigger the target. It's better 
to let the script trigger the buildotherwise user can't invoke the tool outside 
the make environment(e.g. from jenkins job, precommit hook or command line).
   
Why is the building of the host tools not part of the top level make 
process? Shouldn't the host tools be built  So that there is a sane environment 
prior to building the config target?


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: [DISCUSS] Simple Workflow Proposal - not so simple?

[Gregory Nutt]

I think the process should be as simple as possible, and improved later. Just
select the absolute bare minimum that could start to work and discard everything
else so this project can work again.


Depends on what you mean by simple.  Using some less-than-simple tools 
can make the workflow very simple.  I believe that we need to establish 
a set of very high-level workflow requirements.  Then we have the top 
level roadmap that could guide  a simple initial implementation and 
could be improved later with the same objective in mind.


That does not preclude any change in direction, requirements can change 
too.  But the roadmap would be controlled by consensus approval (not the 
implementation!  only the roadmap).   Such a roadmap would unify our 
mindset and unify our sense of purpose. There is anarchy, rogue 
behaviors, and distrust now that could be fixed by a simple 
roadmap/high-level requirements that makes sense to everyone.

[GitHub] [incubator-nuttx] patacongo commented on issue #2: Master pr nxstyle improvments

[GitBox]

patacongo commented on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568527990
 
 
   Because most of them are not needed for the build.  And it just wastes build 
cycles building tools that are not used.  You ran into this with nxstyle.exe 
only because it was not on used in the build before your change.  The build 
target in the Makefile is nice because it only builds the executable if it will 
be needed.


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] patacongo commented on issue #2: Master pr nxstyle improvments

[GitBox]

patacongo commented on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568528569
 
 
   This will build all of the tools including a dozen or so that you don't need 
and probably will never need:
   
   $(MAKE) -C tools -f Makefile.host
   
   


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: [DISCUSS] Simple Workflow Proposal - not so simple?

[Nathan Hartman]

On Mon, Dec 23, 2019 at 11:06 AM Sebastien Lorquet  wrote:
>
> OK.
>
> That is too much email for me, I just cant follow and understand all these
> discussions anymore. Almost 300 messages among multiple overlapping threads 
> full
> of heated opinions in 2-3 days is insane.
>
> I just cant dedicate enough time reading any more of this. I have other things
> to do than trying to understand these multiple rebooted workflows proposals 
> that
> span days (and nights!) of discussions.

It helps if you have a mail client that can display messages in
threaded mode. If not, you could (for example) create a gmail account.
Gmail automatically groups related emails. This has the advantage of
separating the volume of NuttX emails from your regular email box.

Regarding the workflow:

The road is bumpy but everything will be okay. This is a learning
experience for everyone. We are in the deep end of the swimming pool
with no training wheels. It is a big change and there is some shock,
chaos, and arguments. But everything will be okay. We have version
control. If a bad commit is made it can be fixed.

Brennan created a page in the Confluence for the workflow document. I
know that only committers can edit the Confluence wiki directly but
that is not a problem: Anyone can write some text and email it to this
list, and a committer can edit it into the Confluence page. (Hint:
People who participate often become good candidates to become
committers too!)

The Workflow Work-In-Progress Confluence Page is here:
https://cwiki.apache.org/confluence/display/NUTTXTEST/Code+Contribution+Workflow+--+Brennan+Ashton

On purpose I am not writing the whole thing by myself because I do not
want to be pushy. This is a community effort. I already wrote much and
it is in the Confluence page above. My plan is to wait a week or two,
let people work, and let discussions happen.

Let's relax. Let cooler minds prevail. Trust that the Apache Way
works. And everything will be okay.

Nathan

[GitHub] [incubator-nuttx] xiaoxiang781216 commented on issue #2: Master pr nxstyle improvments

[GitBox]

xiaoxiang781216 commented on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568532088
 
 
   > > Yes, but we already have the rule in tools/Makefile.host for generating 
nxstyle binary, the question is where should we trigger the target. It's better 
to let the script trigger the buildotherwise user can't invoke the tool outside 
the make environment(e.g. from jenkins job, precommit hook or command line).
   > 
   > Why is the building of the host tools not part of the top level make 
process? Shouldn't the host tools be built So that there is a sane environment 
prior to building the config target?
   
   Because user may run the script without issue any make command first, for 
example:
   The jenkins job could run the script check the style before build to save 
the time.
   As Greg indicate, we can build nxstyle with one line command:
   make -C tools -f Makefile.host nxstyle
   But it's very helpful to issue the above command in the script, because many 
user even expert don't know this trick.


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: [DISCUSS] Simple Workflow Proposal - not so simple?

[Gregory Nutt]

Brennan created a page in the Confluence for the workflow document. I
know that only committers can edit the Confluence wiki directly but
that is not a problem: Anyone can write some text and email it to this
list, and a committer can edit it into the Confluence page. (Hint:
People who participate often become good candidates to become
committers too!)

The Workflow Work-In-Progress Confluence Page is here:
https://cwiki.apache.org/confluence/display/NUTTXTEST/Code+Contribution+Workflow+--+Brennan+Ashton


There is a thread on 
https://mail-archives.apache.org/mod_mbox/nuttx-dev/ called [CALL for 
TOP Down workflow Requirements].  Currently it contains all workflow 
thoughts. Please feel free to comment there mostly forwarded from other 
discussion threads.  There is not a lot there :'(, but that is what we 
have to work with.  We should probably keep discussion as terse as 
possiblethere.  These threads with 100's of responses are, as you note, 
pretty difficult to follow.  If we keep things terse then there is less 
chance that you input will be lost in the clutter.

[GitHub] [incubator-nuttx] patacongo closed pull request #2: Master pr nxstyle improvments

[GitBox]

patacongo closed pull request #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/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] patacongo edited a comment on issue #2: Master pr nxstyle improvments

[GitBox]

patacongo edited a comment on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568537008
 
 
   > But it's very helpful to issue the above command in the script, because 
many user even expert don't know this trick.
   
   There are also cases where scripts in tools/ build the binaries that the 
scipt needs.  This makes the scripts nicely self-contained. 
   
   Examples...  Logic assocated with:
   
   tools/mkconfigvars.sh:KCONFIG2MAKEFILE=Makefile.host
   tools/refresh.sh:CMPCONFIGMAKEFILE=Makefile.host
   
   


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] patacongo commented on issue #2: Master pr nxstyle improvments

[GitBox]

patacongo commented on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568537008
 
 
   > But it's very helpful to issue the above command in the script, because 
many user even expert don't know this trick.
   
   There are also lots of cases where scripts in tools/ build the binaries that 
the scipt needs.  This makes the scripts nicely self-contained. 
   
   Examples...  Logic assocated with:
   
   tools/mkconfigvars.sh:KCONFIG2MAKEFILE=Makefile.host
   tools/refresh.sh:CMPCONFIGMAKEFILE=Makefile.host
   
   


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: [DISCUSS] Simple Workflow Proposal - not so simple?

[Disruptive Solutions]

+1 keep it simple

Verstuurd vanaf mijn iPhone

> Op 23 dec. 2019 om 17:06 heeft Sebastien Lorquet  het 
> volgende geschreven:
> 
> OK.
> 
> That is too much email for me, I just cant follow and understand all these
> discussions anymore. Almost 300 messages among multiple overlapping threads 
> full
> of heated opinions in 2-3 days is insane.
> 
> I just cant dedicate enough time reading any more of this. I have other things
> to do than trying to understand these multiple rebooted workflows proposals 
> that
> span days (and nights!) of discussions.
> 
> So I can't vote on anything. I dont understand what is going on anymore. I'm
> lost. Probably not important since I did not ask and choose to be a committer,
> but since opinions are asked, here are mine.
> 
> 
> Can someone please sum up what we have to decide in a short email, less than 
> a page?
> 
> 
> To be honest, viewed from here, I just seem to understand that some opinions 
> are
> very pushy and are trying to act before decisions are settled.
> 
> Also some kind of extra-heavy decisions on a full process NO ONE has been able
> to install up to now for years.
> 
> I just want to say that going to apache should not be an occasion to try to
> force the process of someone liking or another just because not everyone has 
> an
> equally stronger opinion and voice and free time for emails.
> 
> On my part, seeing too hard pushes in any specific direction just rings an 
> alarm
> bell to be extra-cautious.
> 
> 
> I think the process should be as simple as possible, and improved later. Just
> select the absolute bare minimum that could start to work and discard 
> everything
> else so this project can work again.
> 
> 
> We are using git so things are reversable, right? We will not get this right 
> the
> first time, so lets keep room for errors. If I understand correctly the
> bitbucket repositories are still in a consistent pre-apache state and the 
> apache
> ones can be reset? or is the apache->bb mirroring already active?
> 
> Also, I did not see a notification that the BB repositories had been frozen.
> 
> 
> These workflow and reviewing discussions are just killing extremely valuable
> time for everyone without visible progress (because too many messages).
> 
> 
> So again, I would like to read a very short state of the union at monday
> 2019-Dec-23 17:01 UTC+1.
> 
> Otherwise I cant make decisions. And I guess I am not the only one.
> 
> 
> Sebastien
> 
> 
>> Le 22/12/2019 à 17:25, Gregory Nutt a écrit :
>> 
>>> Let's get everyone's thoughts on the table
>> 
>> I suppose that we should keep the discussion for 72 hours then call the 
>> vote. 
>> We need to allow time for everyone to comment and with the holidays, we may
>> not be able to get good feedback. Should we still call a vote if people are
>> not participating?
>> 
>> I will call the vote on your behalf in 72 hours.
>> 
>> Greg
>> 
>> 
>> 
> 

[GitHub] [incubator-nuttx] patacongo commented on issue #2: Master pr nxstyle improvments

[GitBox]

patacongo commented on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568537855
 
 
   Sorry about the Open/Close/Open/Close.  Not exactly sure what I am doing.  I 
suspect that it is the "Close and Comment" button next to the "Comment" button. 
 I am used to hitting a "Cancel" button at that position.


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] davids5 commented on issue #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568538098
 
 
   Is it that you both are too close to the solution space that you cannot see
   this from a N00B perspective?
   
   
   
   Do you have tab completion on make installed?
   
   
   
   Assume want to grow the NuttX community.
   
   Assume the first question is "What is make?"
   
   
   
   One interface in a dev environment is the "user" interface at any skill
   level will further the effort and it does not hinder the "pros"
   
   
   
   
   
   
   
   
   
   
   
   *From:* patacongo [mailto:notificati...@github.com]
   *Sent:* Monday, December 23, 2019 9:07 AM
   *To:* apache/incubator-nuttx
   *Cc:* David Sidrane; Mention
   *Subject:* Re: [apache/incubator-nuttx] Master pr nxstyle improvments (#2)
   
   
   
   This will build all of the tools including a dozen or so that you don't
   need and probably will never need:
   
   $(MAKE) -C tools -f Makefile.host
   
   —
   You are receiving this because you were mentioned.
   Reply to this email directly, view it on GitHub
   
,
   or unsubscribe
   

   .
   


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] patacongo edited a comment on issue #2: Master pr nxstyle improvments

[GitBox]

patacongo edited a comment on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568537855
 
 
   Sorry about the Open/Close/Open/Close.  Not exactly sure what I am doing.  I 
suspect that it is the "Close and Comment" button next to the "Comment" button. 
 I am used to hitting a "Cancel" button at that position.
   
   Grrr.. still says closed.  Clicking open the pull requests menu page does 
seem to do it.


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] davids5 commented on issue #2: Master pr nxstyle improvments

[GitBox]

davids5 commented on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568538442
 
 
   LOL - RTM,  If we had CI you would have swapped it.
   
   
   
   *From:* patacongo [mailto:notificati...@github.com]
   *Sent:* Monday, December 23, 2019 9:46 AM
   *To:* apache/incubator-nuttx
   *Cc:* David Sidrane; Mention
   *Subject:* Re: [apache/incubator-nuttx] Master pr nxstyle improvments (#2)
   
   
   
   Sorry about the Open/Close/Open/Close. Not exactly sure what I am doing. I
   suspect that it is the "Close and Comment" button next to the "Comment"
   button. I am used to hitting a "Cancel" button at that position.
   
   —
   You are receiving this because you were mentioned.
   Reply to this email directly, view it on GitHub
   
,
   or unsubscribe
   

   .
   


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] patacongo edited a comment on issue #2: Master pr nxstyle improvments

[GitBox]

patacongo edited a comment on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568537855
 
 
   Sorry about the Open/Close/Open/Close.  Not exactly sure what I am doing.  I 
suspect that it is the "Close and Comment" button next to the "Comment" button. 
 I am used to hitting a "Cancel" button at that position.
   
   Grrr.. still says closed.  Clicking open the pull requests menu page does 
NOT seem to do it.


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] davids5 opened a new pull request #2: Master pr nxstyle improvments

[GitBox]

davids5 opened a new pull request #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2
 
 
   @patacongo - 
   
   This will get us off the ground on the formatting tool we can get in to the 
workfow.
   
   We are going to need your expertise on the the makefile side.  (be nice i 
got it to work ;)
   
   There should be no formatting check changes - it just get us a tool that 
will work with compiler aware ide/editors.
   
   `make check_format` - will check all the files that differ from `master`
   
   
![image](https://user-images.githubusercontent.com/1945821/71326515-da16e900-24b0-11ea-89dd-3d64c2b4ba15.png)
   
   `tools/check_code_style.sh  file name` will check a file
   


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] patacongo edited a comment on issue #2: Master pr nxstyle improvments

[GitBox]

patacongo edited a comment on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568537855
 
 
   Sorry about the Open/Close/Open/Close.  Not exactly sure what I am doing.  I 
suspect that it is the "Close and Comment" button next to the "Comment" button. 
 I am used to hitting a "Cancel" button at that position.
   
   Grrr.. still says closed.  Clicking open the pull requests menu page does 
NOT seem to do it.  Obviously, "a button below the comment box."  No not 
obvious.


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] patacongo edited a comment on issue #2: Master pr nxstyle improvments

[GitBox]

patacongo edited a comment on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568537855
 
 
   Sorry about the Open/Close/Open/Close.  Not exactly sure what I am doing.  I 
suspect that it is the "Close and Comment" button next to the "Comment" button. 
 I am used to hitting a "Cancel" button at that position.
   
   Grrr.. still says closed.  Clicking open on the pull requests menu page does 
NOT seem to do it.  Obviously, "a button below the comment box."  No not so 
obvious.


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] patacongo commented on issue #2: Master pr nxstyle improvments

[GitBox]

patacongo commented on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568540319
 
 
   I don't think Xaio Xiang's proposal and your implementation are mutually 
exclusive.


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

Ethernet over USB on Arduino Due

[Adam Feuer]

Hi,

Does anyone know if it's possible to do Ethernet over USB on NuttX on the
Arduino Due? For instance, like Alan Carvalho de Assis discusses in this
Youtube video ?

I can get a minimal NuttX installation working without TCP/IP and UDP/IP
networking. But configuring the Arduino Due like Alan says doesn't exactly
work for this board... with some modifications I can get it to almost
compile, but I'm down to this last missing function:

void up_usbinitialize(void)

This only seems present in sam_udp.c, which seems to only be included in
the sam4 boards, not sam3 boards like the Arduino.

Is it possible to get Ethernet over USB working on the Arduino Due (sam3)?
If so, does anyone have any hints on what to do? The sam_udp.c file
implements a USB Device Port. What is that? Would I need to implement one
for the sam3? If so, does anyone know if there is an example for the sam3?

-adam

ps. Here's the end of my compile output for reference in case it helps:

LD: nuttx
arm-none-eabi-ld:
/home/adamf/src/nuttx-arduino-due/nuttx/staging/libarch.a(up_initialize.o):
in function `up_initialize':
/home/adamf/src/nuttx-arduino-due/nuttx/arch/arm/src/common/up_initialize.c:271:
undefined reference to `up_usbinitialize'
make[1]: *** [Makefile:185: nuttx] Error 1
make[1]: Leaving directory
'/home/adamf/src/nuttx-arduino-due/nuttx/arch/arm/src'
make: *** [tools/Makefile.unix:472: pass2] Error 2


-- 
Adam Feuer 

Re: [DISCUSS] Simple Workflow Proposal - not so simple?

[Justin Mclean]

Hi,

> Brennan created a page in the Confluence for the workflow document. I
> know that only committers can edit the Confluence wiki directly but
> that is not a problem: Anyone can write some text and email it to this
> list, and a committer can edit it into the Confluence page. 

Non committers can also ask for access.

Thanks,
Justin

Re: Ethernet over USB on Arduino Due

[Gregory Nutt]

..., but I'm down to this last missing function:

void up_usbinitialize(void)


Defined here:

$ grep -r up_usbinitialize arch/arm/src/sam34
arch/arm/src/sam34/sam_udp.c: * Name: up_usbinitialize
arch/arm/src/sam34/sam_udp.c:void up_usbinitialize(void)
arch/arm/src/sam34/sam_udp.c:   * in when up_usbinitialize() was first 
called.


Sound like a configuration problem:


146 ifeq ($(CONFIG_SAM34_UDP),y)
147 CHIP_CSRCS += sam_udp.c
148 endif

[GitHub] [incubator-nuttx] mubes commented on issue #1: imxrt fixes

[GitBox]

mubes commented on issue #1: imxrt fixes 
URL: https://github.com/apache/incubator-nuttx/pull/1#issuecomment-568570219
 
 
   Way back when DavidS and I talked about this at length and then there was a 
lot of work done in imxrt to split it into the different chips - 1050, 60 and 
20 to form the various hardware/rt10xx directories.
   
   At the moment the only place there is any family member selection (other 
than to pull in the correct chip specific subdir) is in imxrt_clockconfig.c, 
imxrt_gpio.c and imxrt_iomux.c. Those can (and probably should) be refactored 
into the same pattern as the other files which, I think, would keep the 
structure clean.
   
   Does that satisfy your concern @btashton , or are you looking for a more 
fundamental restructure?  (BTW, this structure is a nicer way of highlighting 
changes and having proper discussion about them to find the best way forward).
   
   DAVE
   


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] btashton commented on issue #1: imxrt fixes

[GitBox]

btashton commented on issue #1: imxrt fixes 
URL: https://github.com/apache/incubator-nuttx/pull/1#issuecomment-568574794
 
 
   @mubes No complaints on my end (beyond the tedious task of transcribing 
datasheets to code).  This family has been handled so much better by NXP than 
ST did with the STM32 family.
   
   There are a few things I have tweaked across all of the devices, but that is 
mostly minor and usually just using a better define for example because not all 
have PADMUX_WAKEUP:
   ```
   -  if (index >= IMXRT_PADMUX_WAKEUP_INDEX)
   +  if (index >= IMXRT_PADMUX_SNVS_START_INDEX)
   ```
   
   Also a couple typeo's like
   ```
   -#define GPIO_LPSPI1_SDI_2  (GPIO_PERIPH | GPIO_ALT4 | 
GPIO_PADMUX(IMXRT_PADMUX_GPIO_SD_B0_05_INDEX))fb
   +#define GPIO_LPSPI1_SDI_2  (GPIO_PERIPH | GPIO_ALT4 | 
GPIO_PADMUX(IMXRT_PADMUX_GPIO_SD_B0_05_INDEX))
   ```
   
   There is also a GPIOMUX that they added to help with the lower pincount 
while still allowing high speed GPIO.  Anyway I need to just get this stuff out 
for comment.  Probably need a couple nights to get the core code done, not sure 
how long the board bit will take.  The memory interfaces are a little 
different. 
   
   Anyway this is getting off topic for this PR.  I'll put a DRAFT PR up before 
I get the board code done, either a here or on my fork.  
   
   @davids5 I have not forgotten about your offer, just will likely need to 
wait until the 1st with travel.


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] mubes commented on issue #1: imxrt fixes

[GitBox]

mubes commented on issue #1: imxrt fixes 
URL: https://github.com/apache/incubator-nuttx/pull/1#issuecomment-568575636
 
 
   Yeah, lets move this onto another PR so we can fix up whatever needs to be 
done to solidify the filesystem structure for the rt's. Certainly I think 
moving the GPIOs, IOMUX and ClockConfig into the subdirectory will go a long 
way to fixing whats outstanding (well, that and fixing Mr. Hamfisteds' typos).
   
   DAVE
   


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] patacongo edited a comment on issue #2: Master pr nxstyle improvments

[GitBox]

patacongo edited a comment on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568540319
 
 
   I don't think Xaio Xiang's proposal and your implementation are mutually 
exclusive.
   
   Correct me if I am misreading things, but I believe that the situation here 
is that David services to masters, primarily PX4 and secondarily NuttX.  So his 
objective will always be to submt the optimal PX4 solution and then attempt to 
bulldoze it through, regardless of what we feel about it.  I presume that is 
why he is so opposed to having high level workflow requirements because they 
may conflict with PX4.
   
   The may be a good thing, but one side effect that that whatever you may 
think will probably be ignored.  The PX4 code is not open to compromise for 
NuttX.  We will just have to see how all of this works out.  Be careful but be 
open minded.


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] patacongo edited a comment on issue #2: Master pr nxstyle improvments

[GitBox]

patacongo edited a comment on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568540319
 
 
   I don't think Xaio Xiang's proposal and your implementation are mutually 
exclusive.
   
   Correct me if I am misreading things, but I believe that the situation here 
is that David serves two masters, primarily PX4 and secondarily NuttX.  So his 
objective will always be to submt the optimal PX4 solution and then attempt to 
bulldoze it through, regardless of what we feel about it.  I presume that is 
why he is so opposed to having high level workflow requirements because they 
may conflict with PX4.
   
   The may be a good thing, but one side effect that that whatever you may 
think will probably be ignored.  The PX4 code is not open to compromise for 
NuttX.  We will just have to see how all of this works out.  Be careful but be 
open minded.


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: [DISCUSS] Simple Workflow Proposal - not so simple?

[Disruptive Solutions]

Did you look at  https://www.atlassian.com/nl/software/crucible ??
And:  https://www.perforce.com/solutions/static-analysis

https://www.atlassian.com/git/tutorials/comparing-workflows

 The concept "The Centralized Workflow" was the "old" workflow, but now
maybe the concept "Feature branching" is maybe a way to go? Say there are
people working on "features" in Nuttx? Drivers, Kernel, Apps, etc?? Or is
"Gitflow" already" choosen?

Ben





Op ma 23 dec. 2019 om 20:27 schreef Justin Mclean
:

> Hi,
>
> > Brennan created a page in the Confluence for the workflow document. I
> > know that only committers can edit the Confluence wiki directly but
> > that is not a problem: Anyone can write some text and email it to this
> > list, and a committer can edit it into the Confluence page.
>
> Non committers can also ask for access.
>
> Thanks,
> Justin
>

Power Management on the L432KC

[Disruptive Solutions]

A content question (I think this is possible?) .

I want to use the STANDBY mode in Power Management in the Nucleo-L432KC.
Now I am reading that in the STM32 Power Management is implemented.

What is the best way to get this working for the L432KC? I see that in arch
there are some power routines implemented. The standby register settings
"look" ok.

Say I want to trigger (event when power fails and "line" is pulled down) it
sets the Nucleo in "STANDBY" so my RTC is still "OK". And the coin battery
(CR2032) kicks in...

Then I want it to get back "ALIVE" again when I put a rising edge on WKUP1
(PA0) event...

How could I best tackle this?

Thanks.
Ben

Re: Power Management on the L432KC

[Gregory Nutt]

I want to use the STANDBY mode in Power Management in the Nucleo-L432KC.
Now I am reading that in the STM32 Power Management is implemented.

What is the best way to get this working for the L432KC? I see that in arch
there are some power routines implemented. The standby register settings
"look" ok.

Say I want to trigger (event when power fails and "line" is pulled down) it
sets the Nucleo in "STANDBY" so my RTC is still "OK". And the coin battery
(CR2032) kicks in...

Then I want it to get back "ALIVE" again when I put a rising edge on WKUP1
(PA0) event...

How could I best tackle this?


Use the NuttX PM (Power Management) subsystem.  Search through the 
boards defconfig files for CONFIG_PM for some very simple examples.  
There is no real documentation (only this 
http://www.nuttx.org/doku.php?id=documentation:pmreport).  More real 
world usage is more complex.  I don't believe that there is any 
defconfig for the STM32L4 family so that will be an interesting challenge.

[GitHub] [incubator-nuttx] patacongo edited a comment on issue #2: Master pr nxstyle improvments

[GitBox]

patacongo edited a comment on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568540319
 
 
   I don't think Xaio Xiang's proposal and your implementation are mutually 
exclusive.
   
   Correct me if I am misreading things, but I believe that the situation here 
is that David serves two masters, primarily PX4 and secondarily NuttX.  So his 
objective will always be to submit the optimal PX4 solution and then attempt to 
bulldoze it through, regardless of what we feel about it.  I presume that is 
why he is so opposed to having high level workflow requirements because they 
may conflict with PX4.
   
   The may be a good thing, but one side effect that that whatever you may 
think will probably be ignored.  The PX4 code is not open to compromise for 
NuttX.  We will just have to see how all of this works out.  Be careful but be 
open minded.


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: Power Management on the L432KC

[Gregory Nutt]

I want to use the STANDBY mode in Power Management in the Nucleo-L432KC.
Now I am reading that in the STM32 Power Management is implemented.

What is the best way to get this working for the L432KC? I see that 
in arch

there are some power routines implemented. The standby register settings
"look" ok.

Say I want to trigger (event when power fails and "line" is pulled 
down) it
sets the Nucleo in "STANDBY" so my RTC is still "OK". And the coin 
battery

(CR2032) kicks in...

Then I want it to get back "ALIVE" again when I put a rising edge on 
WKUP1

(PA0) event...

How could I best tackle this?


Use the NuttX PM (Power Management) subsystem.  Search through the 
boards defconfig files for CONFIG_PM for some very simple examples.  
There is no real documentation (only this 
http://www.nuttx.org/doku.php?id=documentation:pmreport).  More real 
world usage is more complex.  I don't believe that there is any 
defconfig for the STM32L4 family so that will be an interesting challenge


There might be something useful to you in this post: 
https://groups.google.com/forum/#!searchin/nuttx/power$20management|sort:date/nuttx/1q7jIsrRW5I/wOhaPYDwAAAJ

Re: Power Management on the L432KC

[Disruptive Solutions]

Thank you I will look into it!

Verstuurd vanaf mijn iPhone

> Op 24 dec. 2019 om 00:05 heeft Gregory Nutt  het 
> volgende geschreven:
> 
> 
>>> I want to use the STANDBY mode in Power Management in the Nucleo-L432KC.
>>> Now I am reading that in the STM32 Power Management is implemented.
>>> 
>>> What is the best way to get this working for the L432KC? I see that in arch
>>> there are some power routines implemented. The standby register settings
>>> "look" ok.
>>> 
>>> Say I want to trigger (event when power fails and "line" is pulled down) it
>>> sets the Nucleo in "STANDBY" so my RTC is still "OK". And the coin battery
>>> (CR2032) kicks in...
>>> 
>>> Then I want it to get back "ALIVE" again when I put a rising edge on WKUP1
>>> (PA0) event...
>>> 
>>> How could I best tackle this?
>> 
>> Use the NuttX PM (Power Management) subsystem.  Search through the boards 
>> defconfig files for CONFIG_PM for some very simple examples.  There is no 
>> real documentation (only this 
>> http://www.nuttx.org/doku.php?id=documentation:pmreport).  More real world 
>> usage is more complex.  I don't believe that there is any defconfig for the 
>> STM32L4 family so that will be an interesting challenge
> 
> There might be something useful to you in this post: 
> https://groups.google.com/forum/#!searchin/nuttx/power$20management|sort:date/nuttx/1q7jIsrRW5I/wOhaPYDwAAAJ
> 
> 

[GitHub] [incubator-nuttx] patacongo commented on issue #2: Master pr nxstyle improvments

[GitBox]

patacongo commented on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568604222
 
 
   I would like to close this now.  I do not think it should be incorporated 
into the NuttX repositories now.  It deals with specific logic for the NuttX 
workflow.  We need to have a defintiion for the workflow before we can consider 
including it.
   
   Then we need to bring all of the other people on board who are tasked with 
working with the NuttX: Haitao Liu and Anthony Merlino.  A slam dunk of PX4 
workflow is not acceptable.


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] patacongo closed pull request #2: Master pr nxstyle improvments

[GitBox]

patacongo closed pull request #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/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] patacongo edited a comment on issue #2: Master pr nxstyle improvments

[GitBox]

patacongo edited a comment on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568604222
 
 
   I would like to close this now.  I do not think it should be incorporated 
into the NuttX repositories now.  It deals with specific logic for the NuttX 
workflow.  We need to have a defintiion for the workflow before we can consider 
including it.
   
   Then we need to bring all of the other people on board who are tasked with 
working with the NuttX: Haitao Liu and Anthony Merlino.  A slam dunk of PX4 
workflow is not acceptable.
   
   This time, I did not accidentally hid the button. I really did intend to 
close the PR.


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] patacongo edited a comment on issue #2: Master pr nxstyle improvments

[GitBox]

patacongo edited a comment on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568604222
 
 
   I would like to close this now.  I do not think it should be incorporated 
into the NuttX repositories now.  It deals with specific logic for the NuttX 
workflow.  We need to have a defintiion for the workflow before we can consider 
including it.
   
   Then we need to bring all of the other people on board who are tasked with 
working with the NuttX: Haitao Liu and Anthony Merlino.  A slam dunk of PX4 
workflow is not acceptable.
   
   We should revisit this in the future when there is an agreed upon work flow 
and when all participants in the development of the NuttX workflow are on board 
and have the opportunity to voice their support or concerns.
   
   This time, I did not accidentally hit the button. I really did intend to 
close the PR.


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] patacongo edited a comment on issue #2: Master pr nxstyle improvments

[GitBox]

patacongo edited a comment on issue #2: Master pr nxstyle improvments
URL: https://github.com/apache/incubator-nuttx/pull/2#issuecomment-568604222
 
 
   I would like to close this now.  I do not think it should be incorporated 
into the NuttX repositories now.  It deals with specific logic for the NuttX 
workflow.  We need to have a defintiion for the workflow before we can consider 
including it.
   
   Then we need to bring all of the other people on board who are tasked with 
working with the NuttX: Haitao Liu and Anthony Merlino.  A slam dunk of PX4 
workflow is not acceptable.
   
   We should revisit this in the future when there is an agreed upon work flow 
and when all participants in the development of the NuttX workflow are on board 
and have the opportunity to voice their support or concerns.
   
   This time, I did not accidentally hit the button. I really did intend to 
close the PR.  But let's not consider it finally closed.  It is closed until 
can define the workflow requirements and get all of the relevant parties 
involved.


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: Ethernet over USB on Arduino Due

[Gregory Nutt]

I don't think that the SAM3X8E supports the UDP module.  Looks like it 
supports UDPHS which would be different: 
https://www.microchip.com/wwwproducts/en/ATsam3x8e#additional-features 
See also arch/arm/include/sam34/chip.h.


There is a hardware/sam_udphs.h header file, but I don't see any udphs 
driver.


I would say that the driver has never been implemented.

There is a sama5/sam_udphs.c driver.  Perhaps that could be backported 
if the IP is the same?


Greg

On 12/23/2019 6:08 PM, Adam Feuer wrote:

Thanks Greg.

When I manually edit the .config file and add this:

CONFIG_SAM34_UDP=y

Then try to make again, I get a bunch of errors for missing defines 
(PMC_UDP, SAM_IRQ_UDP, etc.). These seem to be defined in 
arch/arm/src/sam34/hardware/sam_pmc.h, but only for 
CONFIG_ARCH_CHIP_SAM4S or CONFIG_ARCH_CHIP_SAM4E, not for SAM3 like 
the Arduino Due:


https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/sam34/hardware/sam_pmc.h#L212

I tried to follow these undefined identifiers and made some changes 
that got nuttx to compile. But when I flash nuttx.bin to the board 
using bossac, I get a blinking RX light, which indicates a panic.


Here's the changes I made:

https://github.com/apache/incubator-nuttx/compare/master...adamfeuer:feature/arduino-due-ethernet-over-usb

I guess I need to debug this too. :) Any tips? Did I do something 
wrong with these modifications?


cheers
adam


On Mon, Dec 23, 2019 at 11:43 AM Gregory Nutt > wrote:


..., but I'm down to this last missing function:
> void up_usbinitialize(void)

Defined here:

$ grep -r up_usbinitialize arch/arm/src/sam34
arch/arm/src/sam34/sam_udp.c: * Name: up_usbinitialize
arch/arm/src/sam34/sam_udp.c:void up_usbinitialize(void)
arch/arm/src/sam34/sam_udp.c:   * in when up_usbinitialize() was
first
called.

Sound like a configuration problem:


146 ifeq ($(CONFIG_SAM34_UDP),y)
147 CHIP_CSRCS += sam_udp.c
148 endif



--
Adam Feuer mailto:a...@starcat.io>>

Single Committer

[Gregory Nutt]

Recent events have made me reconsider some decisions I made.  I threw 
off the single committer mantle when I saw the abuse of privilege in the 
repositories.  If the PPMC agrees to it, I will take up that role again.


But let's be frank.  Here is what I think that means:

 * I would be sole committer of changes.  The repositories would have
   to be treated as read-only just as back in the Bitbucket days.
 * I would grandfather in the i.MXRT changes.
 * I will decline all workflow related changes until workflow
   requirements are established (that is my only real motivation for
   suggesting this:  To make certain that we have proper requirements
   in place before we accept PX4 workflow into our repositories.  We
   need to do this right and I am willing to protect the repositories
   until the workflow requirements are established.  I expect that to
   take about two weeks.)
 * I would create a dev branch and expect all PRs to be against that
   dev branch.
 * As soon as the PPMC is confident that it has the processes in place
   to handle the commit workload I will gladly relinquish this role.
 * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
   expedite the avalanche of commits expected after the holidays.

If any of this concerns people, please "Just Say No."  I am not married 
to the idea and I am not forcefully advocating it.  This is what people 
wanted me to do a few days ago and if I can protect our right to define 
the workflow, then I will do it.  For me it is a sacrifice that I would 
take with no pleasure in.


Pros:  This will provide project continuity until the PPMC is fully 
functional.  Having workflow requirements will be a huge step in that 
direction.  People stressed about the commit process can relax with 
confidence.  This will protect the code base from premature work flow 
changes until we have an understanding of what we want.  No harm is done 
by deferring workflow changes until we as a team are prepared to deal 
with them.


Cons:  This is not the Apache way.  People who are trying to bulldoze 
the PX4 work flow into the repositories will hate the idea.  Mentors 
will hate the idea.  An approach more consistent with the Apache way 
would just be to let the chaos prevail.  That is fine with me too as 
long as we do not let PX4 advocates take away our group right to define 
our own workflow.  We can still just put all workflow changes on hold 
until we have the requirements in hand.


I am not pushing anything.  Think about it and let me know what you 
would like to do.


Greg

[GitHub] [incubator-nuttx] patacongo merged pull request #1: imxrt fixes

[GitBox]

patacongo merged pull request #1: imxrt fixes 
URL: https://github.com/apache/incubator-nuttx/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: Single Committer

[Duo Zhang]

+1.

I think it is reasonable to just keep the original workflow as is for now,
as we still need to make progress on the project. I do not think the ASF
will 'hate' this, you can not graduate if you keep doing things like this,
that's all, fair enough.

And on the workflow part, I suggest you start another thread sir, to
explain the checks you have done when verifying a patch, and also the
requirements. I think first we should reach an agreement on the checks and
requirements, and then we could see which parts can be automate and which
parts can only be handled by human, and see how can we enforce them, by a
'workflow'.

Thanks.

Gregory Nutt  于2019年12月24日周二 上午8:51写道：

> Recent events have made me reconsider some decisions I made.  I threw
> off the single committer mantle when I saw the abuse of privilege in the
> repositories.  If the PPMC agrees to it, I will take up that role again.
>
> But let's be frank.  Here is what I think that means:
>
>   * I would be sole committer of changes.  The repositories would have
> to be treated as read-only just as back in the Bitbucket days.
>   * I would grandfather in the i.MXRT changes.
>   * I will decline all workflow related changes until workflow
> requirements are established (that is my only real motivation for
> suggesting this:  To make certain that we have proper requirements
> in place before we accept PX4 workflow into our repositories.  We
> need to do this right and I am willing to protect the repositories
> until the workflow requirements are established.  I expect that to
> take about two weeks.)
>   * I would create a dev branch and expect all PRs to be against that
> dev branch.
>   * As soon as the PPMC is confident that it has the processes in place
> to handle the commit workload I will gladly relinquish this role.
>   * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
> expedite the avalanche of commits expected after the holidays.
>
> If any of this concerns people, please "Just Say No."  I am not married
> to the idea and I am not forcefully advocating it.  This is what people
> wanted me to do a few days ago and if I can protect our right to define
> the workflow, then I will do it.  For me it is a sacrifice that I would
> take with no pleasure in.
>
> Pros:  This will provide project continuity until the PPMC is fully
> functional.  Having workflow requirements will be a huge step in that
> direction.  People stressed about the commit process can relax with
> confidence.  This will protect the code base from premature work flow
> changes until we have an understanding of what we want.  No harm is done
> by deferring workflow changes until we as a team are prepared to deal
> with them.
>
> Cons:  This is not the Apache way.  People who are trying to bulldoze
> the PX4 work flow into the repositories will hate the idea.  Mentors
> will hate the idea.  An approach more consistent with the Apache way
> would just be to let the chaos prevail.  That is fine with me too as
> long as we do not let PX4 advocates take away our group right to define
> our own workflow.  We can still just put all workflow changes on hold
> until we have the requirements in hand.
>
> I am not pushing anything.  Think about it and let me know what you
> would like to do.
>
> Greg
>
>
>

Re: [PATCH] doubt about fwrite

[wei peng]

hi David,

Thanks for your reply.

Yes...i know the interface interface is standard,so what i had changed in
codes just repaired the problem.perhaps i should describe the problem  in
detail.


I entering "dmesg" on both terminals，because of the “CONFIG_IOB_DEBUG” is
enable so both of terminals will show messages continuously.
Then close one of them,and the other one will be frozen,after that i cannot
connect the borad (via usart or telnet).but i am sure the systerm is work
on.


I found the "dmesg" command call a function named "int nsh_catfile()",and
in this function,the logic is simple (read message from ramlog and write it
to terminals).
when write it to terminals ,it will call "size_t fwrite()"function, As you
see the size_t is unsigned cannot be negative. that is the problem.
i think if the terminal is close,the "size_t fwrite()"function should
return a negative number,and the nsh_catfile should be broken.

BR,

wei peng

David Sidrane  于2019年12月23日周一 下午5:36写道：

> Hi wei peng
>  See below.
>
> On 2019/12/23 07:41:40, wei peng  wrote:
> > hi~
> >   I connected the target board to terminal via "telnet" ,  in some cases
> > the terminal will be frozen. Here are detailed steps:
> >
> >1. Enable "CONFIG_IOB_DEBUG"[necessary].
> >2. New two terminals and connect to target board via "telnet".
> >3. Input "dmesg" command,and the terminal will show information
> >*continuously*.[two terminals are same][necessary]
> >4. Close one of  the terminals,and the other one will be frozen.but
> the
> >system is work on.
> >
> > I debug the system and repaired the bug,the file named commit.txt is
> > detailed steps.
> > BR,
> >
> > wei peng
>
> The interface is dictated by the OpenGroup stands [1]
> [1] https://pubs.opengroup.org/onlinepubs/009695399/functions/fwrite.html
>
> So that can not be changed.
>
> There must be a root cause related to what you are doing or a bug in the
> system. Check the configuration (compare it to other telnet board configs).
>
> Are you Entering dmesg on both terminals or on one and it is showing up
> the 2 terminals?
>
> David
>
>

Re: [PATCH] doubt about fwrite

[Gregory Nutt]

see the size_t is unsigned cannot be negative. that is the problem.
i think if the terminal is close,the "size_t fwrite()"function should
return a negative number,and the nsh_catfile should be broken.


That is not the way that fwrite returns errors.  If an error occurs 
fwrite returns fewer item than you requested to send.  That is required 
by the specification: 
https://pubs.opengroup.org/onlinepubs/9699919799/functions/fwrite.html


On an error, fwrite will set the errno value and the error indictor


   RETURN VALUE

   The /fwrite/() function shall return the number of elements
   successfully written, which *may be less than **/nitems/**if a write
   error is encountered*. If /size/ or /nitems/ is 0, /fwrite/() shall
   return 0 and the state of the stream remains unchanged.
   Otherwise,*if a write error occurs, the error indicator for the
   stream shall be set*, ^[CX] [Option Start]  and /errno/ shall be set
   to indicate the error.

If fwrite() returns fewer items than you requiested (or zero), you must 
call ferror() to determine if an error occurred: 
https://pubs.opengroup.org/onlinepubs/009695399/functions/ferror.html


If the error indicator is set, you can get the error from the errno 
variable.


The error indicator is cleared with clearerr(): 
https://pubs.opengroup.org/onlinepubs/009695399/functions/clearerr.html


It may not return a negative value.