Re: DISCUSSION - Usage of mailing lists for apache projects
On Wed, 8 Mar 2023 at 13:16, Alan C. Assis wrote: > > > Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear > from you again! You have a great knowledge of BLE can we need! I was > expecting you to share that working example of BLE application using > our BLE stack). > Thanks, I don't know about "great knowledge", but I am not sure I will be doing any bt work this time. I checked. The current BLE stack is broken when I run it on my board with a cc2564 BT chip. The bt command fails to connect like it does on a 2019 tree that I have. I don't know what the point of the changes being made to bluetooth is, if such a basic feature remains broken after a merge. Is anyone really using or testing the NuttX stack?
Re: ESP-Hosted on NuttX
Hi Jernej, The ESP-Hosted is in our plans, but it is not priority now. As you remember in the last NuttX Workshop we had a presentation from Wilderness Labs about Meadow and they have an ESP32 as co-processor that has a USRSOCK communication to allow host MCU to use ESP32 WiFi and Bluetooth. I just talked with Bryan and he suggest working with you to release it as open-source, case you are interested to contribute it back to mainline. BR, Alan On 3/9/23, Jernej Turnsek wrote: > Hi, > has someone make an effort to bring ESP- Hosted to NuttX OS. ESP-Hosted > supports Linux integration and RTOS integration. One could use the RTOS way > to bring ESP-Hosted up, but on the other hand NuttX is more like Linux. > What do you think? > > Regards, > Jernej >
RE: Help me understand file open/close behaviours?
I was wrong. My app was mishandling console input :( >-Original Message- >From: Tim Hardisty >Sent: 09 March 2023 15:34 >To: dev@nuttx.apache.org >Subject: RE: Help me understand file open/close behaviours? > >Guess what - this behaviour is only on Master. Spent an hour or 2 getting >the test app and new driver to work under 12.0 release and I can ctrl-C >out of my test app without problem and re-run it without an apocalyptic >crash. > >I will now raise it as an issue on GitHub. > >>-Original Message- >>From: Tim Hardisty >>Sent: 08 March 2023 17:37 >>To: dev@nuttx.apache.org >>Subject: RE: Help me understand file open/close behaviours? >> >>>From: Gregory Nutt >>>Sent: 03 March 2023 19:03 >>> >>>On 3/3/2023 12:56 PM, Gregory Nutt wrote: On 3/3/2023 12:36 PM, Nathan Hartman wrote: > On Fri, Mar 3, 2023 at 1:07 PM Tim Hardisty >>wrote: >> - I have enabled CONFIG_SIGKILL_ACTION to allow me to ctrl-c from >> the console if the app is misbehaving or, I thought, just to exit >>it. >> >> The behaviours I see are: >> >> 1) If I ctrl-c, the open files are not closed and if I re-run the >> app, the system crashes. It is the very first printf statement of >> the app that causes the crash, at the point the printf routine >> calls lib_fflush (not looked further yet). SIGINT, SIGKILL, etc. don't do graceful shutdowns like exit() does. They should behave as though _exit() were called which does an immediate termination. However, _exit() is still required to close all open file descriptor (Per Linux man page) and, if it does not, that would be a bug. SIGKILL can't be caught (again per the Linux man page) https://man7.org/linux/man-pages/man2/exit.2.html https://man7.org/linux/man-pages/man7/signal.7.html >>>"Closing" per se is probably not a the root of the problem when the >>>file descriptors are deallocated when the task group terminates, all >>>of the descriptors are freed. However, I suspect the there may be an >>>open reference count in the drivers which is not decrements and whcih >>>could subsequently in interfere with the correct behavior or a driver. >>> >>> >> >>To divert from procedural discussion... >> >>I think I take it from the above that a CTRL-C is not a clean exit; but >>is not the root cause of the issue I'm seeing. >> >>The crash is at a printf the very first line of the app. And the same >>is true if I run another example app after a ctrl-c out of my new test >>app that uses printf. It is not to do with any interaction with file >>open/close/ioctl etc. as I first thought. >> >>I don't get why a ctrl-c out of an app causes printf to completely >>crash the board with no useful debug info to be had! The call stack >>simply shows it was due to an ARM data abort exception. >> >>I am quite sure I have made some "daft" Kconfig change (or not made a >>selection I should have done) - I welcome any suggestions before I >>shrug my shoulders and conclude this is just "one of those things" :)
RE: Help me understand file open/close behaviours?
Guess what - this behaviour is only on Master. Spent an hour or 2 getting the test app and new driver to work under 12.0 release and I can ctrl-C out of my test app without problem and re-run it without an apocalyptic crash. I will now raise it as an issue on GitHub. >-Original Message- >From: Tim Hardisty >Sent: 08 March 2023 17:37 >To: dev@nuttx.apache.org >Subject: RE: Help me understand file open/close behaviours? > >>From: Gregory Nutt >>Sent: 03 March 2023 19:03 >> >>On 3/3/2023 12:56 PM, Gregory Nutt wrote: >>> On 3/3/2023 12:36 PM, Nathan Hartman wrote: On Fri, Mar 3, 2023 at 1:07 PM Tim Hardisty >wrote: > - I have enabled CONFIG_SIGKILL_ACTION to allow me to ctrl-c from > the console if the app is misbehaving or, I thought, just to exit >it. > > The behaviours I see are: > > 1) If I ctrl-c, the open files are not closed and if I re-run the > app, the system crashes. It is the very first printf statement of > the app that causes the crash, at the point the printf routine > calls lib_fflush (not looked further yet). >>> >>> SIGINT, SIGKILL, etc. don't do graceful shutdowns like exit() does. >>> They should behave as though _exit() were called which does an >>> immediate termination. However, _exit() is still required to close >>> all open file descriptor (Per Linux man page) and, if it does not, >>> that would be a bug. >>> >>> SIGKILL can't be caught (again per the Linux man page) >>> >>> https://man7.org/linux/man-pages/man2/exit.2.html >>> https://man7.org/linux/man-pages/man7/signal.7.html >>> >>"Closing" per se is probably not a the root of the problem when the >>file descriptors are deallocated when the task group terminates, all of >>the descriptors are freed. However, I suspect the there may be an open >>reference count in the drivers which is not decrements and whcih could >>subsequently in interfere with the correct behavior or a driver. >> >> > >To divert from procedural discussion... > >I think I take it from the above that a CTRL-C is not a clean exit; but >is not the root cause of the issue I'm seeing. > >The crash is at a printf the very first line of the app. And the same is >true if I run another example app after a ctrl-c out of my new test app >that uses printf. It is not to do with any interaction with file >open/close/ioctl etc. as I first thought. > >I don't get why a ctrl-c out of an app causes printf to completely crash >the board with no useful debug info to be had! The call stack simply >shows it was due to an ARM data abort exception. > >I am quite sure I have made some "daft" Kconfig change (or not made a >selection I should have done) - I welcome any suggestions before I shrug >my shoulders and conclude this is just "one of those things" :)
Re: Serial console BROKEN
If CONFIG_SERIAL_TERMIOS is not selected then non-consoles will do nothing. In order to restore legacy behavior you would have to do this: +#ifdef CONFIG_SERIAL_TERMIOS if ( -#ifdef CONFIG_SERIAL_TERMIOS dev->tc_iflag & ECHO -#else - dev->isconsole -#endif ) ... } +#endif That should eliminate the double character echo. So the command line tool has to do the different thing(echo or non echo by self) based on CONFIG_SERIAL_TERMIOS? No, the legacy behavior is that the serial driver never echos by itself unless ECHO is selected.
Re: DISCUSSION - Usage of mailing lists for apache projects
First of all, people never respect pull request formats if this is not enforced. So enforcement is required as well. No member of the PMC has authority over any other. An Apache project is ultra democratic bordering on anarchistic. Each member is basically a "sovereign citizen." So we cannot command anyone to do anything. We cannot assign anyone to do anything. We cannot enforce anything other than through processes and tools. Good arguments with a little social pressure are the only available tools to manage the project. In order to accomplish anything, there really has to be discussion (like this), consensus, and agreement. Achieving that is painful and slow -- and quickly exceeds my ability to be patience. That is what you have to work with.
Re: Manjaro Distro
Yes on this. Distribution provided bare metal arm toolchains have always been a disappointment for me. Sebastien Le 09/03/2023 à 12:03, Petro Karashchenko a écrit : I think the best way is to install GCC from the ARM website and not using OS package manager.
Re: Manjaro Distro
On the libm: some time ago I tried to install the RISCV toolchain on Ubuntu with apt and the installed toolchain was built without libm :) In other words, running compiler + arch flags with "--print-file-name=libm.a" option gave me an empty output (also "find gcc_folder -name libm.a" gave me an empty result). I think the best way is to install GCC from the ARM website and not using OS package manager. For the romfs error, maybe you can try to track romfs generation path and try running it manually from console instead of running it from make. I think it would be easier to narrow down an issue by executing steps manually from the console. Best regards, Petro чт, 9 бер. 2023 р. о 12:01 Simon Filgis пише: > Hi all, > > thanks for answering. > > I'm still in build-phase. No runtime hard-fault. I'm using my fork on > github https://github.com/SimonFilgis/incubator-nuttx > > Mr. Xiao nailed it. It choose to use the NuttX internal libm for the > moment. > > But still something seems to miss, please have a look at the attached log. > > LD: nuttx >> arm-none-eabi-ld --entry=__start -nostdlib --gc-sections --cref >> -Map=/home/simon/projects/autococo2/temp/autococo2fw/nuttx/nuttx.map -g >> -T/home/simon/projects/autococo2/temp/autococo2fw/nuttx/../autococo2-board/scripts/flash.ld >> -L /home/simon/projects/autococo2/temp/autococo2fw/nuttx/staging -L >> /home/simon/projects/autococo2/temp/autococo2fw/nuttx/arch/arm/src/board \ >> -o /home/simon/projects/autococo2/temp/autococo2fw/nuttx/nuttx \ >> --start-group -lsched -ldrivers -lboards -lc -lmm -larch -lapps >> -lnet -lfs -lbinfmt -lboard >> /usr/lib/gcc/arm-none-eabi/12.2.0/thumb/v7e-m+dp/hard/libgcc.a --end-group >> arm-none-eabi-ld: warning: >> /home/simon/projects/autococo2/temp/autococo2fw/nuttx/nuttx has a LOAD >> segment with RWX permissions >> arm-none-eabi-ld: >> /home/simon/projects/autococo2/temp/autococo2fw/nuttx/staging/libapps.a(nsh_romfsetc.c.home.simon.projects.autococo2.temp.autococo2fw.apps.nshlib.o): >> in function `nsh_romfsetc': >> /home/simon/projects/autococo2/temp/autococo2fw/apps/nshlib/nsh_romfsetc.c:97: >> undefined reference to `romfs_img_len' >> arm-none-eabi-ld: >> /home/simon/projects/autococo2/temp/autococo2fw/apps/nshlib/nsh_romfsetc.c:97: >> undefined reference to `romfs_img' >> make[1]: *** [Makefile:159: nuttx] Error 1 >> make[1]: Leaving directory >> '/home/simon/projects/autococo2/temp/autococo2fw/nuttx/arch/arm/src' >> make: *** [tools/Unix.mk:509: nuttx] Error 2 >> > > Again romfs_img, I had this with the bitbucket pipeline a few days ago, > xxd was missing. I cannot identify root cause with make V=1 (attached). > > Has anybody an idea? > > Simon > > -- > Hard- and Softwaredevelopment Consultant > Ingenieurbüro-Filgis > USt-IdNr.: DE305343278 > > > On Wed, Mar 8, 2023 at 7:43 PM Gregory Nutt wrote: > >> >> > Hi, >> > >> > I think that some key information is missing like what is the NuttX >> version >> > used. Is it mainline or some release or custom. >> > >> > Best regards, >> > Petro >> >> It would be helpful to understand where and why the crash occurs too. >> You can get that information by analyzing the stack. See >> >> https://cwiki.apache.org/confluence/display/NUTTX/Analyzing+Cortex-M+Hardfaults >> for an example. >> >> Without know why the hard fault occurs that is nothing anyone can really >> do or say to be helpful (unless the problem can be replicated). >> >>
Re: DISCUSSION - Usage of mailing lists for apache projects
sorry wrong calculation, I meant 7 days * 0.5 hour * 50% * 4 weeks = 7 hours per month. Still a lot, which could be saved by a few minutes of your company time per week for specific PRs. Cause not all them need careful review. Sebastien Le 09/03/2023 à 11:49, Sebastien Lorquet a écrit : I understand that, but also, you should not force your high-speed development pace on other developers :) Because it also consumes a huge resource to review your requests :-) You asked me to spend half an hour a day on PR review, but you send 50% of all PRs, so this amounts to (7*0.5)*4 = 14 hours of free hard work for Xiaomi each month! This is not possible without a commercial contract. You are the large company, you have employees and financial resources, you should be doing the work, not project volunteers. Sebastien Le 09/03/2023 à 11:42, Xiang Xiao a écrit : If so, most likely xiaomi will fork nuttx like Samuang and make our own change. We don't want to spend the time to prepare the patch but no feedback guarantee, since it consumes a huge resource to prepare the patch. On Thu, Mar 9, 2023 at 6:15 PM Sebastien Lorquet wrote: Hi, This sounds like a corporate rule, does it? Not being critical here, this is just to understand. There should be no clear limit for a shared project, we just need time to take the best decisions. I feel that you cant force progress if there are no resources to do it. Remember, most of us are volunteers, right? That means you should not try to overcome volunteer availability by enforcing decisions. That also means you could have a company managed "staging repository" to match the speed you need for your internal products and roadmap, while upstream contributions are discussed and validated. I believe progress should happen more naturally if the issue is presented to us with an explanation that you actually need decisions on a point. Sebastien Le 09/03/2023 à 10:52, Xiang Xiao a écrit : Yes, this is how I do normally, but we need the rule to ensure the PR gets progress. e.g. the reviewer needs to give the feedback in one week, one month or one year. The reviewer has the rights to approve the change and also has duties to make progress. On Thu, Mar 9, 2023 at 5:14 PM alin.jerpe...@sony.com < alin.jerpe...@sony.com> wrote: Hi Xiang, Simply add some reviewers on the right side and they will be notified that someone asks them to step up Best regards Alin -Original Message- From: Xiang Xiao Sent: den 9 mars 2023 10:12 To: dev@nuttx.apache.org Subject: Re: DISCUSSION - Usage of mailing lists for apache projects If some PR waits for a long time without any review, how to make progress? For example, this PR sent two weaks ago: https://github.com/apache/nuttx/pull/8610 On Thu, Mar 9, 2023 at 4:40 PM alin.jerpe...@sony.com < alin.jerpe...@sony.com> wrote: Hi all, I feel that this thread is getting too long without a real outcome Some observations from my daily interactions with the project: - I like doing reviews on github and I think that many people in this thread would agree that this flow is good. - I like to be able to see all bugs in one place and get statistics for the ASF reports What I don’t feel right - even if I spend time daily on reviewing patches there are still changes that I miss and it is hard to get the flow on release date - some breaking changes are not discussed enough with the community since there are some people that do not have time to review code on gihub. As a way going forward I propose that we improve in 2 aspects - All breaking commits should be discusses on dev so that people get enough time to digest the change and even better get involved int the flow - all breaking changes should be documented on the release confluence page before merging so that we don’t miss mentioning them on release date. - there should be at least 1 independent reviewer (not from the same company) so that a patch is merged except board changes (ex an employee from the same company merges a patch submitted by another employee from the same company, for a board provided by the same company) Thanks Alin -Original Message- From: Alan C. Assis Sent: den 8 mars 2023 19:15 To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: Re: DISCUSSION - Usage of mailing lists for apache projects Hi Lwazi, It is not sarcarm, I'm talking about facts. Also I didn't say Sebastien points aren't valid, but is diverting from the real issue. The issue is not if the discussion is happening here or there, the Problem is that we don't have enough reviewers. So, first step is that NuttX needs to increase the user base, but have few users really engaged with the project, reviewing patches every single day. Currently today he have few: Petro and Xiang are exceptional on this point. They are my inspiration to try do more! Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear from you again! You have a
Re: DISCUSSION - Usage of mailing lists for apache projects
I understand that, but also, you should not force your high-speed development pace on other developers :) Because it also consumes a huge resource to review your requests :-) You asked me to spend half an hour a day on PR review, but you send 50% of all PRs, so this amounts to (7*0.5)*4 = 14 hours of free hard work for Xiaomi each month! This is not possible without a commercial contract. You are the large company, you have employees and financial resources, you should be doing the work, not project volunteers. Sebastien Le 09/03/2023 à 11:42, Xiang Xiao a écrit : If so, most likely xiaomi will fork nuttx like Samuang and make our own change. We don't want to spend the time to prepare the patch but no feedback guarantee, since it consumes a huge resource to prepare the patch. On Thu, Mar 9, 2023 at 6:15 PM Sebastien Lorquet wrote: Hi, This sounds like a corporate rule, does it? Not being critical here, this is just to understand. There should be no clear limit for a shared project, we just need time to take the best decisions. I feel that you cant force progress if there are no resources to do it. Remember, most of us are volunteers, right? That means you should not try to overcome volunteer availability by enforcing decisions. That also means you could have a company managed "staging repository" to match the speed you need for your internal products and roadmap, while upstream contributions are discussed and validated. I believe progress should happen more naturally if the issue is presented to us with an explanation that you actually need decisions on a point. Sebastien Le 09/03/2023 à 10:52, Xiang Xiao a écrit : Yes, this is how I do normally, but we need the rule to ensure the PR gets progress. e.g. the reviewer needs to give the feedback in one week, one month or one year. The reviewer has the rights to approve the change and also has duties to make progress. On Thu, Mar 9, 2023 at 5:14 PM alin.jerpe...@sony.com < alin.jerpe...@sony.com> wrote: Hi Xiang, Simply add some reviewers on the right side and they will be notified that someone asks them to step up Best regards Alin -Original Message- From: Xiang Xiao Sent: den 9 mars 2023 10:12 To: dev@nuttx.apache.org Subject: Re: DISCUSSION - Usage of mailing lists for apache projects If some PR waits for a long time without any review, how to make progress? For example, this PR sent two weaks ago: https://github.com/apache/nuttx/pull/8610 On Thu, Mar 9, 2023 at 4:40 PM alin.jerpe...@sony.com < alin.jerpe...@sony.com> wrote: Hi all, I feel that this thread is getting too long without a real outcome Some observations from my daily interactions with the project: - I like doing reviews on github and I think that many people in this thread would agree that this flow is good. - I like to be able to see all bugs in one place and get statistics for the ASF reports What I don’t feel right - even if I spend time daily on reviewing patches there are still changes that I miss and it is hard to get the flow on release date - some breaking changes are not discussed enough with the community since there are some people that do not have time to review code on gihub. As a way going forward I propose that we improve in 2 aspects - All breaking commits should be discusses on dev so that people get enough time to digest the change and even better get involved int the flow - all breaking changes should be documented on the release confluence page before merging so that we don’t miss mentioning them on release date. - there should be at least 1 independent reviewer (not from the same company) so that a patch is merged except board changes (ex an employee from the same company merges a patch submitted by another employee from the same company, for a board provided by the same company) Thanks Alin -Original Message- From: Alan C. Assis Sent: den 8 mars 2023 19:15 To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: Re: DISCUSSION - Usage of mailing lists for apache projects Hi Lwazi, It is not sarcarm, I'm talking about facts. Also I didn't say Sebastien points aren't valid, but is diverting from the real issue. The issue is not if the discussion is happening here or there, the Problem is that we don't have enough reviewers. So, first step is that NuttX needs to increase the user base, but have few users really engaged with the project, reviewing patches every single day. Currently today he have few: Petro and Xiang are exceptional on this point. They are my inspiration to try do more! Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear from you again! You have a great knowledge of BLE can we need! I was expecting you to share that working example of BLE application using our BLE stack). BR, Alan On 3/8/23, Lwazi Dube wrote: On Wed, 8 Mar 2023 at 09:55, Alan C. Assis wrote: Sebastien, If all the discussions that happens on github start to happen here, this mailing
Re: Shell alias support for NSH
Thanks for the responses This feature already exist > https://github.com/apache/nuttx-apps/blob/master/nshlib/Kconfig#L126-L146 > As far as I can understand, that is for backquotes `foo` which is a type of variable expansion. What I need is support for single quotes 'foo' which means that whatever is inside '' is just a string litral. Or do you mean that the variable expansion support is already there ? Does posix say something about shells? > Yes POSIX demands that the aliases are stored per session only. BR, Ville Juven > On Thu, Mar 9, 2023 at 12:35 PM Xiang Xiao wrote: > On Thu, Mar 9, 2023 at 6:14 PM Ville Juven wrote: > > > Hi all, > > > > I'm in the process of writing support for shell aliases into NSH, but > since > > the shell is the front end for NuttX I decided to make a post here for > > opinions on this matter and to open discussion for requirements, mostly > to > > prevent unexpected regression issues that might arise from this. > > > > 1. Are shell aliases seen as something useful in the community ? I need > > them for a project of mine which is the reason I started implementing > > support but I'd like to know if they are seen as useful whatsoever by > > others. > > > > 2. To properly support aliases, the shell parser needs to support single > > quotes and double quotes. This support will generate a bit of extra code > > into the parser, is this seen as OK ? > > > > alias foo='bar baz' > > alias foo="bar $baz" > > > > In both cases, the parser stops on the first delimiter (whitespace) even > > though it is quoted. > > > > 3. I will implement support for *single quotes* as this is a simple case > > but not for double quotes as the rules are more complex (need to perform > > variable expansions etc). Is this seen as a blocker / fatal issue? > > > > > This feature already exist > https://github.com/apache/nuttx-apps/blob/master/nshlib/Kconfig#L126-L146 > > > > 4. I added a Kconfig option to turn alias support on/off, what should the > > default state of this option be ? Currently it is defined as follows: > > > > config NSH_ALIAS > > bool "Enable alias support" > > default !DEFAULT_SMALL > > > > I noticed that many of the shell features are flagged behind > DEFAULT_SMALL. > > > > Also the alias amount is configurable. > > > > 5. Currently aliases are implemented globally i.e. every shell shares the > > same aliases, is this seen as a problem or should I make the aliases > stick > > to a shell session only ? > > > > > It's better to follow the POSIX spec. > > This is my first time posting on this board, so apologies if I did > > something improper. > > > > Br, Ville Juven > > >
Re: Shell alias support for NSH
Hi, If I am not mistaken, the existing NSH_CMDPARMS feature will just execute the command once and copy the stdout into the var? Aliases are more like virtual commands, that execute their contents when run. This is distinct from built-in commands and user implemented programs. Sebastien Le 09/03/2023 à 11:34, Xiang Xiao a écrit : This feature already exist https://github.com/apache/nuttx-apps/blob/master/nshlib/Kconfig#L126-L146
Re: DISCUSSION - Usage of mailing lists for apache projects
If so, most likely xiaomi will fork nuttx like Samuang and make our own change. We don't want to spend the time to prepare the patch but no feedback guarantee, since it consumes a huge resource to prepare the patch. On Thu, Mar 9, 2023 at 6:15 PM Sebastien Lorquet wrote: > Hi, > > This sounds like a corporate rule, does it? Not being critical here, > this is just to understand. > > > There should be no clear limit for a shared project, we just need time > to take the best decisions. > > I feel that you cant force progress if there are no resources to do it. > > Remember, most of us are volunteers, right? > > That means you should not try to overcome volunteer availability by > enforcing decisions. > > That also means you could have a company managed "staging repository" to > match the speed you need for your internal products and roadmap, while > upstream contributions are discussed and validated. > > > I believe progress should happen more naturally if the issue is > presented to us with an explanation that you actually need decisions on > a point. > > > Sebastien > > Le 09/03/2023 à 10:52, Xiang Xiao a écrit : > > Yes, this is how I do normally, but we need the rule to ensure the PR > gets > > progress. e.g. the reviewer needs to give the feedback in one week, one > > month or one year. > > The reviewer has the rights to approve the change and also has duties to > > make progress. > > > > > > On Thu, Mar 9, 2023 at 5:14 PM alin.jerpe...@sony.com < > > alin.jerpe...@sony.com> wrote: > > > >> Hi Xiang, > >> > >> Simply add some reviewers on the right side and they will be notified > that > >> someone asks them to step up > >> > >> Best regards > >> Alin > >> > >> > >> -Original Message- > >> From: Xiang Xiao > >> Sent: den 9 mars 2023 10:12 > >> To: dev@nuttx.apache.org > >> Subject: Re: DISCUSSION - Usage of mailing lists for apache projects > >> > >> If some PR waits for a long time without any review, how to make > progress? > >> For example, this PR sent two weaks ago: > >> https://github.com/apache/nuttx/pull/8610 > >> > >> On Thu, Mar 9, 2023 at 4:40 PM alin.jerpe...@sony.com < > >> alin.jerpe...@sony.com> wrote: > >> > >>> Hi all, > >>> > >>> I feel that this thread is getting too long without a real outcome > >>> > >>> Some observations from my daily interactions with the project: > >>> - I like doing reviews on github and I think that many people in this > >>> thread would agree that this flow is good. > >>> - I like to be able to see all bugs in one place and get statistics > >>> for the ASF reports > >>> > >>> What I don’t feel right > >>> - even if I spend time daily on reviewing patches there are still > >>> changes that I miss and it is hard to get the flow on release date > >>> - some breaking changes are not discussed enough with the community > >>> since there are some people that do not have time to review code on > >> gihub. > >>> As a way going forward I propose that we improve in 2 aspects > >>> - All breaking commits should be discusses on dev so that people get > >>> enough time to digest the change and even better get involved int the > >>> flow > >>> - all breaking changes should be documented on the release confluence > >>> page before merging so that we don’t miss mentioning them on release > >> date. > >>> - there should be at least 1 independent reviewer (not from the same > >>> company) so that a patch is merged except board changes (ex an > >>> employee from the same company merges a patch submitted by another > >>> employee from the same company, for a board provided by the same > >>> company) > >>> > >>> Thanks > >>> Alin > >>> > >>> -Original Message- > >>> From: Alan C. Assis > >>> Sent: den 8 mars 2023 19:15 > >>> To: dev@nuttx.apache.org > >>> Cc: Sebastien Lorquet > >>> Subject: Re: DISCUSSION - Usage of mailing lists for apache projects > >>> > >>> Hi Lwazi, > >>> > >>> It is not sarcarm, I'm talking about facts. > >>> > >>> Also I didn't say Sebastien points aren't valid, but is diverting from > >>> the real issue. > >>> > >>> The issue is not if the discussion is happening here or there, the > >>> Problem is that we don't have enough reviewers. > >>> > >>> So, first step is that NuttX needs to increase the user base, but have > >>> few users really engaged with the project, reviewing patches every > >> single day. > >>> Currently today he have few: Petro and Xiang are exceptional on this > >> point. > >>> They are my inspiration to try do more! > >>> > >>> Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear > >>> from you again! You have a great knowledge of BLE can we need! I was > >>> expecting you to share that working example of BLE application using > >>> our BLE stack). > >>> > >>> BR, > >>> > >>> Alan > >>> > >>> On 3/8/23, Lwazi Dube wrote: > On Wed, 8 Mar 2023 at 09:55, Alan C. Assis wrote: > > Sebastien, > > > > If all the discussions that happens on github start to happen here, > > this
Re: Shell alias support for NSH
On Thu, Mar 9, 2023 at 6:14 PM Ville Juven wrote: > Hi all, > > I'm in the process of writing support for shell aliases into NSH, but since > the shell is the front end for NuttX I decided to make a post here for > opinions on this matter and to open discussion for requirements, mostly to > prevent unexpected regression issues that might arise from this. > > 1. Are shell aliases seen as something useful in the community ? I need > them for a project of mine which is the reason I started implementing > support but I'd like to know if they are seen as useful whatsoever by > others. > > 2. To properly support aliases, the shell parser needs to support single > quotes and double quotes. This support will generate a bit of extra code > into the parser, is this seen as OK ? > > alias foo='bar baz' > alias foo="bar $baz" > > In both cases, the parser stops on the first delimiter (whitespace) even > though it is quoted. > > 3. I will implement support for *single quotes* as this is a simple case > but not for double quotes as the rules are more complex (need to perform > variable expansions etc). Is this seen as a blocker / fatal issue? > > This feature already exist https://github.com/apache/nuttx-apps/blob/master/nshlib/Kconfig#L126-L146 > 4. I added a Kconfig option to turn alias support on/off, what should the > default state of this option be ? Currently it is defined as follows: > > config NSH_ALIAS > bool "Enable alias support" > default !DEFAULT_SMALL > > I noticed that many of the shell features are flagged behind DEFAULT_SMALL. > > Also the alias amount is configurable. > > 5. Currently aliases are implemented globally i.e. every shell shares the > same aliases, is this seen as a problem or should I make the aliases stick > to a shell session only ? > > It's better to follow the POSIX spec. This is my first time posting on this board, so apologies if I did > something improper. > > Br, Ville Juven >
Re: Shell alias support for NSH
Hello, I think you did things very,very well, thank you for this. Here is some feedback: 1 - aliases are not required for me, but It could still be a worthwile feature for others, and it's a requirement for you. 2 - this feels ok for me, since this is generally a better behaviour of the shell parser that would benefit other applications, I believe. 3 - partial implementation does not feel blocking for me. yes, double quotes are more complex. I think there is already a config variable for shell var extension? Can you plan your code to slightly facilitate future extensions if choices are to be made? 4 - for backwards compatibility, this feature should not be on by default, but it is a good general improvement of the shell, so with a notification in git logs, I could see this on by default. No strong opinion on this point. 5 - for this point, I would say aliases need to be per session, since global aliases with multiple shells could be security issues or just annoyance when you dont expect them to be there. Thats how it's made in linux shells, right? Does posix say something about shells? I hope more people share their opinions soon. Thank you again for the time you took to write this. Sebastien Le 09/03/2023 à 11:14, Ville Juven a écrit : Hi all, I'm in the process of writing support for shell aliases into NSH, but since the shell is the front end for NuttX I decided to make a post here for opinions on this matter and to open discussion for requirements, mostly to prevent unexpected regression issues that might arise from this. 1. Are shell aliases seen as something useful in the community ? I need them for a project of mine which is the reason I started implementing support but I'd like to know if they are seen as useful whatsoever by others. 2. To properly support aliases, the shell parser needs to support single quotes and double quotes. This support will generate a bit of extra code into the parser, is this seen as OK ? alias foo='bar baz' alias foo="bar $baz" In both cases, the parser stops on the first delimiter (whitespace) even though it is quoted. 3. I will implement support for *single quotes* as this is a simple case but not for double quotes as the rules are more complex (need to perform variable expansions etc). Is this seen as a blocker / fatal issue? 4. I added a Kconfig option to turn alias support on/off, what should the default state of this option be ? Currently it is defined as follows: config NSH_ALIAS bool "Enable alias support" default !DEFAULT_SMALL I noticed that many of the shell features are flagged behind DEFAULT_SMALL. Also the alias amount is configurable. 5. Currently aliases are implemented globally i.e. every shell shares the same aliases, is this seen as a problem or should I make the aliases stick to a shell session only ? This is my first time posting on this board, so apologies if I did something improper. Br, Ville Juven
Re: DISCUSSION - Usage of mailing lists for apache projects
Hi, This sounds like a corporate rule, does it? Not being critical here, this is just to understand. There should be no clear limit for a shared project, we just need time to take the best decisions. I feel that you cant force progress if there are no resources to do it. Remember, most of us are volunteers, right? That means you should not try to overcome volunteer availability by enforcing decisions. That also means you could have a company managed "staging repository" to match the speed you need for your internal products and roadmap, while upstream contributions are discussed and validated. I believe progress should happen more naturally if the issue is presented to us with an explanation that you actually need decisions on a point. Sebastien Le 09/03/2023 à 10:52, Xiang Xiao a écrit : Yes, this is how I do normally, but we need the rule to ensure the PR gets progress. e.g. the reviewer needs to give the feedback in one week, one month or one year. The reviewer has the rights to approve the change and also has duties to make progress. On Thu, Mar 9, 2023 at 5:14 PM alin.jerpe...@sony.com < alin.jerpe...@sony.com> wrote: Hi Xiang, Simply add some reviewers on the right side and they will be notified that someone asks them to step up Best regards Alin -Original Message- From: Xiang Xiao Sent: den 9 mars 2023 10:12 To: dev@nuttx.apache.org Subject: Re: DISCUSSION - Usage of mailing lists for apache projects If some PR waits for a long time without any review, how to make progress? For example, this PR sent two weaks ago: https://github.com/apache/nuttx/pull/8610 On Thu, Mar 9, 2023 at 4:40 PM alin.jerpe...@sony.com < alin.jerpe...@sony.com> wrote: Hi all, I feel that this thread is getting too long without a real outcome Some observations from my daily interactions with the project: - I like doing reviews on github and I think that many people in this thread would agree that this flow is good. - I like to be able to see all bugs in one place and get statistics for the ASF reports What I don’t feel right - even if I spend time daily on reviewing patches there are still changes that I miss and it is hard to get the flow on release date - some breaking changes are not discussed enough with the community since there are some people that do not have time to review code on gihub. As a way going forward I propose that we improve in 2 aspects - All breaking commits should be discusses on dev so that people get enough time to digest the change and even better get involved int the flow - all breaking changes should be documented on the release confluence page before merging so that we don’t miss mentioning them on release date. - there should be at least 1 independent reviewer (not from the same company) so that a patch is merged except board changes (ex an employee from the same company merges a patch submitted by another employee from the same company, for a board provided by the same company) Thanks Alin -Original Message- From: Alan C. Assis Sent: den 8 mars 2023 19:15 To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: Re: DISCUSSION - Usage of mailing lists for apache projects Hi Lwazi, It is not sarcarm, I'm talking about facts. Also I didn't say Sebastien points aren't valid, but is diverting from the real issue. The issue is not if the discussion is happening here or there, the Problem is that we don't have enough reviewers. So, first step is that NuttX needs to increase the user base, but have few users really engaged with the project, reviewing patches every single day. Currently today he have few: Petro and Xiang are exceptional on this point. They are my inspiration to try do more! Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear from you again! You have a great knowledge of BLE can we need! I was expecting you to share that working example of BLE application using our BLE stack). BR, Alan On 3/8/23, Lwazi Dube wrote: On Wed, 8 Mar 2023 at 09:55, Alan C. Assis wrote: Sebastien, If all the discussions that happens on github start to happen here, this mailing list will be just like the nuttx-commits mailing list. I'll take this as sarcasm. Sebastien is making a lot of valid points, in good faith, and being dismissive does not help the community.
Shell alias support for NSH
Hi all, I'm in the process of writing support for shell aliases into NSH, but since the shell is the front end for NuttX I decided to make a post here for opinions on this matter and to open discussion for requirements, mostly to prevent unexpected regression issues that might arise from this. 1. Are shell aliases seen as something useful in the community ? I need them for a project of mine which is the reason I started implementing support but I'd like to know if they are seen as useful whatsoever by others. 2. To properly support aliases, the shell parser needs to support single quotes and double quotes. This support will generate a bit of extra code into the parser, is this seen as OK ? alias foo='bar baz' alias foo="bar $baz" In both cases, the parser stops on the first delimiter (whitespace) even though it is quoted. 3. I will implement support for *single quotes* as this is a simple case but not for double quotes as the rules are more complex (need to perform variable expansions etc). Is this seen as a blocker / fatal issue? 4. I added a Kconfig option to turn alias support on/off, what should the default state of this option be ? Currently it is defined as follows: config NSH_ALIAS bool "Enable alias support" default !DEFAULT_SMALL I noticed that many of the shell features are flagged behind DEFAULT_SMALL. Also the alias amount is configurable. 5. Currently aliases are implemented globally i.e. every shell shares the same aliases, is this seen as a problem or should I make the aliases stick to a shell session only ? This is my first time posting on this board, so apologies if I did something improper. Br, Ville Juven
Re: Manjaro Distro
Hi all, thanks for answering. I'm still in build-phase. No runtime hard-fault. I'm using my fork on github https://github.com/SimonFilgis/incubator-nuttx Mr. Xiao nailed it. It choose to use the NuttX internal libm for the moment. But still something seems to miss, please have a look at the attached log. LD: nuttx > arm-none-eabi-ld --entry=__start -nostdlib --gc-sections --cref > -Map=/home/simon/projects/autococo2/temp/autococo2fw/nuttx/nuttx.map -g > -T/home/simon/projects/autococo2/temp/autococo2fw/nuttx/../autococo2-board/scripts/flash.ld > -L /home/simon/projects/autococo2/temp/autococo2fw/nuttx/staging -L > /home/simon/projects/autococo2/temp/autococo2fw/nuttx/arch/arm/src/board \ > -o /home/simon/projects/autococo2/temp/autococo2fw/nuttx/nuttx \ > --start-group -lsched -ldrivers -lboards -lc -lmm -larch -lapps > -lnet -lfs -lbinfmt -lboard > /usr/lib/gcc/arm-none-eabi/12.2.0/thumb/v7e-m+dp/hard/libgcc.a --end-group > arm-none-eabi-ld: warning: > /home/simon/projects/autococo2/temp/autococo2fw/nuttx/nuttx has a LOAD > segment with RWX permissions > arm-none-eabi-ld: > /home/simon/projects/autococo2/temp/autococo2fw/nuttx/staging/libapps.a(nsh_romfsetc.c.home.simon.projects.autococo2.temp.autococo2fw.apps.nshlib.o): > in function `nsh_romfsetc': > /home/simon/projects/autococo2/temp/autococo2fw/apps/nshlib/nsh_romfsetc.c:97: > undefined reference to `romfs_img_len' > arm-none-eabi-ld: > /home/simon/projects/autococo2/temp/autococo2fw/apps/nshlib/nsh_romfsetc.c:97: > undefined reference to `romfs_img' > make[1]: *** [Makefile:159: nuttx] Error 1 > make[1]: Leaving directory > '/home/simon/projects/autococo2/temp/autococo2fw/nuttx/arch/arm/src' > make: *** [tools/Unix.mk:509: nuttx] Error 2 > Again romfs_img, I had this with the bitbucket pipeline a few days ago, xxd was missing. I cannot identify root cause with make V=1 (attached). Has anybody an idea? Simon -- Hard- and Softwaredevelopment Consultant Ingenieurbüro-Filgis USt-IdNr.: DE305343278 On Wed, Mar 8, 2023 at 7:43 PM Gregory Nutt wrote: > > > Hi, > > > > I think that some key information is missing like what is the NuttX > version > > used. Is it mainline or some release or custom. > > > > Best regards, > > Petro > > It would be helpful to understand where and why the crash occurs too. > You can get that information by analyzing the stack. See > > https://cwiki.apache.org/confluence/display/NUTTX/Analyzing+Cortex-M+Hardfaults > for an example. > > Without know why the hard fault occurs that is nothing anyone can really > do or say to be helpful (unless the problem can be replicated). > >
Re: DISCUSSION - Usage of mailing lists for apache projects
Yes, this is how I do normally, but we need the rule to ensure the PR gets progress. e.g. the reviewer needs to give the feedback in one week, one month or one year. The reviewer has the rights to approve the change and also has duties to make progress. On Thu, Mar 9, 2023 at 5:14 PM alin.jerpe...@sony.com < alin.jerpe...@sony.com> wrote: > Hi Xiang, > > Simply add some reviewers on the right side and they will be notified that > someone asks them to step up > > Best regards > Alin > > > -Original Message- > From: Xiang Xiao > Sent: den 9 mars 2023 10:12 > To: dev@nuttx.apache.org > Subject: Re: DISCUSSION - Usage of mailing lists for apache projects > > If some PR waits for a long time without any review, how to make progress? > For example, this PR sent two weaks ago: > https://github.com/apache/nuttx/pull/8610 > > On Thu, Mar 9, 2023 at 4:40 PM alin.jerpe...@sony.com < > alin.jerpe...@sony.com> wrote: > > > Hi all, > > > > I feel that this thread is getting too long without a real outcome > > > > Some observations from my daily interactions with the project: > > - I like doing reviews on github and I think that many people in this > > thread would agree that this flow is good. > > - I like to be able to see all bugs in one place and get statistics > > for the ASF reports > > > > What I don’t feel right > > - even if I spend time daily on reviewing patches there are still > > changes that I miss and it is hard to get the flow on release date > > - some breaking changes are not discussed enough with the community > > since there are some people that do not have time to review code on > gihub. > > > > As a way going forward I propose that we improve in 2 aspects > > - All breaking commits should be discusses on dev so that people get > > enough time to digest the change and even better get involved int the > > flow > > - all breaking changes should be documented on the release confluence > > page before merging so that we don’t miss mentioning them on release > date. > > - there should be at least 1 independent reviewer (not from the same > > company) so that a patch is merged except board changes (ex an > > employee from the same company merges a patch submitted by another > > employee from the same company, for a board provided by the same > > company) > > > > Thanks > > Alin > > > > -Original Message- > > From: Alan C. Assis > > Sent: den 8 mars 2023 19:15 > > To: dev@nuttx.apache.org > > Cc: Sebastien Lorquet > > Subject: Re: DISCUSSION - Usage of mailing lists for apache projects > > > > Hi Lwazi, > > > > It is not sarcarm, I'm talking about facts. > > > > Also I didn't say Sebastien points aren't valid, but is diverting from > > the real issue. > > > > The issue is not if the discussion is happening here or there, the > > Problem is that we don't have enough reviewers. > > > > So, first step is that NuttX needs to increase the user base, but have > > few users really engaged with the project, reviewing patches every > single day. > > Currently today he have few: Petro and Xiang are exceptional on this > point. > > They are my inspiration to try do more! > > > > Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear > > from you again! You have a great knowledge of BLE can we need! I was > > expecting you to share that working example of BLE application using > > our BLE stack). > > > > BR, > > > > Alan > > > > On 3/8/23, Lwazi Dube wrote: > > > On Wed, 8 Mar 2023 at 09:55, Alan C. Assis wrote: > > >> > > >> Sebastien, > > >> > > >> If all the discussions that happens on github start to happen here, > > >> this mailing list will be just like the nuttx-commits mailing list. > > > > > > I'll take this as sarcasm. Sebastien is making a lot of valid > > > points, in good faith, and being dismissive does not help the > community. > > > > > >
Re: DISCUSSION - Usage of mailing lists for apache projects
First of all, people never respect pull request formats if this is not enforced. So enforcement is required as well. But this is not sufficient by itself, since a programmer's initial impression of a change can be widely and underestimated. Often times you *really need* that pull request integrated asap, so you will minimize its impact. No tool can catch that. Impact evaluation is the responsibility of the busy committer, and it cannot be trusted. This will lead to important problems filtering right through without anyone noticing. So as a conclusion I dont think that it would help a lot. Sebastien Le 09/03/2023 à 10:34, raiden00pl a écrit : - All breaking commits should be discusses on dev so that people get enough time to digest the change and even better get involved int the flow I think "all breaking commits" is too broad and impractical. What about code guarded with CONFIG_EXPERIMENTAL? What about the features just added or fresh architectures? Maybe we should limit this statement to breaking changes in relation to the previous release and not marked as EXPERIMENTAL. Another thing, can we add a simple comment in the "Impact" section of the Nuttx PR template about notifying the list in the case of a breakage change. czw., 9 mar 2023 o 10:24 Sebastien Lorquet napisał(a): Notify the list! Simple as that. If there is no progress, it means this is a complex PR that needs attention. Just adding reviewers keep the issue github-centric. Sebastien Le 09/03/2023 à 10:11, Xiang Xiao a écrit : If some PR waits for a long time without any review, how to make progress? For example, this PR sent two weaks ago: https://github.com/apache/nuttx/pull/8610 On Thu, Mar 9, 2023 at 4:40 PM alin.jerpe...@sony.com < alin.jerpe...@sony.com> wrote: Hi all, I feel that this thread is getting too long without a real outcome Some observations from my daily interactions with the project: - I like doing reviews on github and I think that many people in this thread would agree that this flow is good. - I like to be able to see all bugs in one place and get statistics for the ASF reports What I don’t feel right - even if I spend time daily on reviewing patches there are still changes that I miss and it is hard to get the flow on release date - some breaking changes are not discussed enough with the community since there are some people that do not have time to review code on gihub. As a way going forward I propose that we improve in 2 aspects - All breaking commits should be discusses on dev so that people get enough time to digest the change and even better get involved int the flow - all breaking changes should be documented on the release confluence page before merging so that we don’t miss mentioning them on release date. - there should be at least 1 independent reviewer (not from the same company) so that a patch is merged except board changes (ex an employee from the same company merges a patch submitted by another employee from the same company, for a board provided by the same company) Thanks Alin -Original Message- From: Alan C. Assis Sent: den 8 mars 2023 19:15 To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: Re: DISCUSSION - Usage of mailing lists for apache projects Hi Lwazi, It is not sarcarm, I'm talking about facts. Also I didn't say Sebastien points aren't valid, but is diverting from the real issue. The issue is not if the discussion is happening here or there, the Problem is that we don't have enough reviewers. So, first step is that NuttX needs to increase the user base, but have few users really engaged with the project, reviewing patches every single day. Currently today he have few: Petro and Xiang are exceptional on this point. They are my inspiration to try do more! Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear from you again! You have a great knowledge of BLE can we need! I was expecting you to share that working example of BLE application using our BLE stack). BR, Alan On 3/8/23, Lwazi Dube wrote: On Wed, 8 Mar 2023 at 09:55, Alan C. Assis wrote: Sebastien, If all the discussions that happens on github start to happen here, this mailing list will be just like the nuttx-commits mailing list. I'll take this as sarcasm. Sebastien is making a lot of valid points, in good faith, and being dismissive does not help the community.
ESP-Hosted on NuttX
Hi, has someone make an effort to bring ESP- Hosted to NuttX OS. ESP-Hosted supports Linux integration and RTOS integration. One could use the RTOS way to bring ESP-Hosted up, but on the other hand NuttX is more like Linux. What do you think? Regards, Jernej
Re: DISCUSSION - Usage of mailing lists for apache projects
> - All breaking commits should be discusses on dev so that people get enough time to digest the change and even better get involved int the flow I think "all breaking commits" is too broad and impractical. What about code guarded with CONFIG_EXPERIMENTAL? What about the features just added or fresh architectures? Maybe we should limit this statement to breaking changes in relation to the previous release and not marked as EXPERIMENTAL. Another thing, can we add a simple comment in the "Impact" section of the Nuttx PR template about notifying the list in the case of a breakage change. czw., 9 mar 2023 o 10:24 Sebastien Lorquet napisał(a): > Notify the list! > > Simple as that. > > If there is no progress, it means this is a complex PR that needs > attention. > > Just adding reviewers keep the issue github-centric. > > Sebastien > > Le 09/03/2023 à 10:11, Xiang Xiao a écrit : > > If some PR waits for a long time without any review, how to make > progress? > > For example, this PR sent two weaks ago: > > https://github.com/apache/nuttx/pull/8610 > > > > On Thu, Mar 9, 2023 at 4:40 PM alin.jerpe...@sony.com < > > alin.jerpe...@sony.com> wrote: > > > >> Hi all, > >> > >> I feel that this thread is getting too long without a real outcome > >> > >> Some observations from my daily interactions with the project: > >> - I like doing reviews on github and I think that many people in this > >> thread would agree that this flow is good. > >> - I like to be able to see all bugs in one place and get statistics for > >> the ASF reports > >> > >> What I don’t feel right > >> - even if I spend time daily on reviewing patches there are still > changes > >> that I miss and it is hard to get the flow on release date > >> - some breaking changes are not discussed enough with the community > since > >> there are some people that do not have time to review code on gihub. > >> > >> As a way going forward I propose that we improve in 2 aspects > >> - All breaking commits should be discusses on dev so that people get > >> enough time to digest the change and even better get involved int the > flow > >> - all breaking changes should be documented on the release confluence > page > >> before merging so that we don’t miss mentioning them on release date. > >> - there should be at least 1 independent reviewer (not from the same > >> company) so that a patch is merged except board changes (ex an employee > >> from the same company merges a patch submitted by another employee from > the > >> same company, for a board provided by the same company) > >> > >> Thanks > >> Alin > >> > >> -Original Message- > >> From: Alan C. Assis > >> Sent: den 8 mars 2023 19:15 > >> To: dev@nuttx.apache.org > >> Cc: Sebastien Lorquet > >> Subject: Re: DISCUSSION - Usage of mailing lists for apache projects > >> > >> Hi Lwazi, > >> > >> It is not sarcarm, I'm talking about facts. > >> > >> Also I didn't say Sebastien points aren't valid, but is diverting from > the > >> real issue. > >> > >> The issue is not if the discussion is happening here or there, the > Problem > >> is that we don't have enough reviewers. > >> > >> So, first step is that NuttX needs to increase the user base, but have > few > >> users really engaged with the project, reviewing patches every single > day. > >> Currently today he have few: Petro and Xiang are exceptional on this > point. > >> They are my inspiration to try do more! > >> > >> Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear > >> from you again! You have a great knowledge of BLE can we need! I was > >> expecting you to share that working example of BLE application using our > >> BLE stack). > >> > >> BR, > >> > >> Alan > >> > >> On 3/8/23, Lwazi Dube wrote: > >>> On Wed, 8 Mar 2023 at 09:55, Alan C. Assis wrote: > Sebastien, > > If all the discussions that happens on github start to happen here, > this mailing list will be just like the nuttx-commits mailing list. > >>> I'll take this as sarcasm. Sebastien is making a lot of valid points, > >>> in good faith, and being dismissive does not help the community. > >>> >
Re: DISCUSSION - Usage of mailing lists for apache projects
Notify the list! Simple as that. If there is no progress, it means this is a complex PR that needs attention. Just adding reviewers keep the issue github-centric. Sebastien Le 09/03/2023 à 10:11, Xiang Xiao a écrit : If some PR waits for a long time without any review, how to make progress? For example, this PR sent two weaks ago: https://github.com/apache/nuttx/pull/8610 On Thu, Mar 9, 2023 at 4:40 PM alin.jerpe...@sony.com < alin.jerpe...@sony.com> wrote: Hi all, I feel that this thread is getting too long without a real outcome Some observations from my daily interactions with the project: - I like doing reviews on github and I think that many people in this thread would agree that this flow is good. - I like to be able to see all bugs in one place and get statistics for the ASF reports What I don’t feel right - even if I spend time daily on reviewing patches there are still changes that I miss and it is hard to get the flow on release date - some breaking changes are not discussed enough with the community since there are some people that do not have time to review code on gihub. As a way going forward I propose that we improve in 2 aspects - All breaking commits should be discusses on dev so that people get enough time to digest the change and even better get involved int the flow - all breaking changes should be documented on the release confluence page before merging so that we don’t miss mentioning them on release date. - there should be at least 1 independent reviewer (not from the same company) so that a patch is merged except board changes (ex an employee from the same company merges a patch submitted by another employee from the same company, for a board provided by the same company) Thanks Alin -Original Message- From: Alan C. Assis Sent: den 8 mars 2023 19:15 To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: Re: DISCUSSION - Usage of mailing lists for apache projects Hi Lwazi, It is not sarcarm, I'm talking about facts. Also I didn't say Sebastien points aren't valid, but is diverting from the real issue. The issue is not if the discussion is happening here or there, the Problem is that we don't have enough reviewers. So, first step is that NuttX needs to increase the user base, but have few users really engaged with the project, reviewing patches every single day. Currently today he have few: Petro and Xiang are exceptional on this point. They are my inspiration to try do more! Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear from you again! You have a great knowledge of BLE can we need! I was expecting you to share that working example of BLE application using our BLE stack). BR, Alan On 3/8/23, Lwazi Dube wrote: On Wed, 8 Mar 2023 at 09:55, Alan C. Assis wrote: Sebastien, If all the discussions that happens on github start to happen here, this mailing list will be just like the nuttx-commits mailing list. I'll take this as sarcasm. Sebastien is making a lot of valid points, in good faith, and being dismissive does not help the community.
Re: DISCUSSION - Usage of mailing lists for apache projects
+1 100% from me, too. Sebastien Le 09/03/2023 à 10:18, David Sidrane a écrit : +1 100% I think that the PR should have a summary as well to ensure it is all tied together. Unless we enable rebase/squash the information will be disjoint. David -Original Message- From: alin.jerpe...@sony.com Sent: Thursday, March 9, 2023 4:13 AM To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: RE: DISCUSSION - Usage of mailing lists for apache projects Hi all, I agree with David but in my opinion this information should go in the commit message and no commit without message should be merged. Not all people will check the PR message but you will always see the reasons simply by typing "git log" if they are in the commit message What do you think ? Thanks Alin -Original Message- From: David Sidrane Sent: den 9 mars 2023 10:00 To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: RE: DISCUSSION - Usage of mailing lists for apache projects I would add that all pull request must have a statement explaining the reason or motivation for the change(s). Just stating the "What" was done is not enough. There must be a "Why" the change is needed. David -Original Message- From: alin.jerpe...@sony.com Sent: Thursday, March 9, 2023 3:39 AM To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: RE: DISCUSSION - Usage of mailing lists for apache projects Hi all, I feel that this thread is getting too long without a real outcome Some observations from my daily interactions with the project: - I like doing reviews on github and I think that many people in this thread would agree that this flow is good. - I like to be able to see all bugs in one place and get statistics for the ASF reports What I don’t feel right - even if I spend time daily on reviewing patches there are still changes that I miss and it is hard to get the flow on release date - some breaking changes are not discussed enough with the community since there are some people that do not have time to review code on gihub. As a way going forward I propose that we improve in 2 aspects - All breaking commits should be discusses on dev so that people get enough time to digest the change and even better get involved int the flow - all breaking changes should be documented on the release confluence page before merging so that we don’t miss mentioning them on release date. - there should be at least 1 independent reviewer (not from the same company) so that a patch is merged except board changes (ex an employee from the same company merges a patch submitted by another employee from the same company, for a board provided by the same company) Thanks Alin -Original Message- From: Alan C. Assis Sent: den 8 mars 2023 19:15 To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: Re: DISCUSSION - Usage of mailing lists for apache projects Hi Lwazi, It is not sarcarm, I'm talking about facts. Also I didn't say Sebastien points aren't valid, but is diverting from the real issue. The issue is not if the discussion is happening here or there, the Problem is that we don't have enough reviewers. So, first step is that NuttX needs to increase the user base, but have few users really engaged with the project, reviewing patches every single day. Currently today he have few: Petro and Xiang are exceptional on this point. They are my inspiration to try do more! Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear from you again! You have a great knowledge of BLE can we need! I was expecting you to share that working example of BLE application using our BLE stack). BR, Alan On 3/8/23, Lwazi Dube wrote: On Wed, 8 Mar 2023 at 09:55, Alan C. Assis wrote: Sebastien, If all the discussions that happens on github start to happen here, this mailing list will be just like the nuttx-commits mailing list. I'll take this as sarcasm. Sebastien is making a lot of valid points, in good faith, and being dismissive does not help the community.
RE: DISCUSSION - Usage of mailing lists for apache projects
+1 100% I think that the PR should have a summary as well to ensure it is all tied together. Unless we enable rebase/squash the information will be disjoint. David -Original Message- From: alin.jerpe...@sony.com Sent: Thursday, March 9, 2023 4:13 AM To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: RE: DISCUSSION - Usage of mailing lists for apache projects Hi all, I agree with David but in my opinion this information should go in the commit message and no commit without message should be merged. Not all people will check the PR message but you will always see the reasons simply by typing "git log" if they are in the commit message What do you think ? Thanks Alin -Original Message- From: David Sidrane Sent: den 9 mars 2023 10:00 To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: RE: DISCUSSION - Usage of mailing lists for apache projects I would add that all pull request must have a statement explaining the reason or motivation for the change(s). Just stating the "What" was done is not enough. There must be a "Why" the change is needed. David -Original Message- From: alin.jerpe...@sony.com Sent: Thursday, March 9, 2023 3:39 AM To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: RE: DISCUSSION - Usage of mailing lists for apache projects Hi all, I feel that this thread is getting too long without a real outcome Some observations from my daily interactions with the project: - I like doing reviews on github and I think that many people in this thread would agree that this flow is good. - I like to be able to see all bugs in one place and get statistics for the ASF reports What I don’t feel right - even if I spend time daily on reviewing patches there are still changes that I miss and it is hard to get the flow on release date - some breaking changes are not discussed enough with the community since there are some people that do not have time to review code on gihub. As a way going forward I propose that we improve in 2 aspects - All breaking commits should be discusses on dev so that people get enough time to digest the change and even better get involved int the flow - all breaking changes should be documented on the release confluence page before merging so that we don’t miss mentioning them on release date. - there should be at least 1 independent reviewer (not from the same company) so that a patch is merged except board changes (ex an employee from the same company merges a patch submitted by another employee from the same company, for a board provided by the same company) Thanks Alin -Original Message- From: Alan C. Assis Sent: den 8 mars 2023 19:15 To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: Re: DISCUSSION - Usage of mailing lists for apache projects Hi Lwazi, It is not sarcarm, I'm talking about facts. Also I didn't say Sebastien points aren't valid, but is diverting from the real issue. The issue is not if the discussion is happening here or there, the Problem is that we don't have enough reviewers. So, first step is that NuttX needs to increase the user base, but have few users really engaged with the project, reviewing patches every single day. Currently today he have few: Petro and Xiang are exceptional on this point. They are my inspiration to try do more! Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear from you again! You have a great knowledge of BLE can we need! I was expecting you to share that working example of BLE application using our BLE stack). BR, Alan On 3/8/23, Lwazi Dube wrote: > On Wed, 8 Mar 2023 at 09:55, Alan C. Assis wrote: >> >> Sebastien, >> >> If all the discussions that happens on github start to happen here, >> this mailing list will be just like the nuttx-commits mailing list. > > I'll take this as sarcasm. Sebastien is making a lot of valid points, > in good faith, and being dismissive does not help the community. >
RE: DISCUSSION - Usage of mailing lists for apache projects
Hi Xiang, Simply add some reviewers on the right side and they will be notified that someone asks them to step up Best regards Alin -Original Message- From: Xiang Xiao Sent: den 9 mars 2023 10:12 To: dev@nuttx.apache.org Subject: Re: DISCUSSION - Usage of mailing lists for apache projects If some PR waits for a long time without any review, how to make progress? For example, this PR sent two weaks ago: https://github.com/apache/nuttx/pull/8610 On Thu, Mar 9, 2023 at 4:40 PM alin.jerpe...@sony.com < alin.jerpe...@sony.com> wrote: > Hi all, > > I feel that this thread is getting too long without a real outcome > > Some observations from my daily interactions with the project: > - I like doing reviews on github and I think that many people in this > thread would agree that this flow is good. > - I like to be able to see all bugs in one place and get statistics > for the ASF reports > > What I don’t feel right > - even if I spend time daily on reviewing patches there are still > changes that I miss and it is hard to get the flow on release date > - some breaking changes are not discussed enough with the community > since there are some people that do not have time to review code on gihub. > > As a way going forward I propose that we improve in 2 aspects > - All breaking commits should be discusses on dev so that people get > enough time to digest the change and even better get involved int the > flow > - all breaking changes should be documented on the release confluence > page before merging so that we don’t miss mentioning them on release date. > - there should be at least 1 independent reviewer (not from the same > company) so that a patch is merged except board changes (ex an > employee from the same company merges a patch submitted by another > employee from the same company, for a board provided by the same > company) > > Thanks > Alin > > -Original Message- > From: Alan C. Assis > Sent: den 8 mars 2023 19:15 > To: dev@nuttx.apache.org > Cc: Sebastien Lorquet > Subject: Re: DISCUSSION - Usage of mailing lists for apache projects > > Hi Lwazi, > > It is not sarcarm, I'm talking about facts. > > Also I didn't say Sebastien points aren't valid, but is diverting from > the real issue. > > The issue is not if the discussion is happening here or there, the > Problem is that we don't have enough reviewers. > > So, first step is that NuttX needs to increase the user base, but have > few users really engaged with the project, reviewing patches every single day. > Currently today he have few: Petro and Xiang are exceptional on this point. > They are my inspiration to try do more! > > Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear > from you again! You have a great knowledge of BLE can we need! I was > expecting you to share that working example of BLE application using > our BLE stack). > > BR, > > Alan > > On 3/8/23, Lwazi Dube wrote: > > On Wed, 8 Mar 2023 at 09:55, Alan C. Assis wrote: > >> > >> Sebastien, > >> > >> If all the discussions that happens on github start to happen here, > >> this mailing list will be just like the nuttx-commits mailing list. > > > > I'll take this as sarcasm. Sebastien is making a lot of valid > > points, in good faith, and being dismissive does not help the community. > > >
RE: DISCUSSION - Usage of mailing lists for apache projects
Hi all, I agree with David but in my opinion this information should go in the commit message and no commit without message should be merged. Not all people will check the PR message but you will always see the reasons simply by typing "git log" if they are in the commit message What do you think ? Thanks Alin -Original Message- From: David Sidrane Sent: den 9 mars 2023 10:00 To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: RE: DISCUSSION - Usage of mailing lists for apache projects I would add that all pull request must have a statement explaining the reason or motivation for the change(s). Just stating the "What" was done is not enough. There must be a "Why" the change is needed. David -Original Message- From: alin.jerpe...@sony.com Sent: Thursday, March 9, 2023 3:39 AM To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: RE: DISCUSSION - Usage of mailing lists for apache projects Hi all, I feel that this thread is getting too long without a real outcome Some observations from my daily interactions with the project: - I like doing reviews on github and I think that many people in this thread would agree that this flow is good. - I like to be able to see all bugs in one place and get statistics for the ASF reports What I don’t feel right - even if I spend time daily on reviewing patches there are still changes that I miss and it is hard to get the flow on release date - some breaking changes are not discussed enough with the community since there are some people that do not have time to review code on gihub. As a way going forward I propose that we improve in 2 aspects - All breaking commits should be discusses on dev so that people get enough time to digest the change and even better get involved int the flow - all breaking changes should be documented on the release confluence page before merging so that we don’t miss mentioning them on release date. - there should be at least 1 independent reviewer (not from the same company) so that a patch is merged except board changes (ex an employee from the same company merges a patch submitted by another employee from the same company, for a board provided by the same company) Thanks Alin -Original Message- From: Alan C. Assis Sent: den 8 mars 2023 19:15 To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: Re: DISCUSSION - Usage of mailing lists for apache projects Hi Lwazi, It is not sarcarm, I'm talking about facts. Also I didn't say Sebastien points aren't valid, but is diverting from the real issue. The issue is not if the discussion is happening here or there, the Problem is that we don't have enough reviewers. So, first step is that NuttX needs to increase the user base, but have few users really engaged with the project, reviewing patches every single day. Currently today he have few: Petro and Xiang are exceptional on this point. They are my inspiration to try do more! Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear from you again! You have a great knowledge of BLE can we need! I was expecting you to share that working example of BLE application using our BLE stack). BR, Alan On 3/8/23, Lwazi Dube wrote: > On Wed, 8 Mar 2023 at 09:55, Alan C. Assis wrote: >> >> Sebastien, >> >> If all the discussions that happens on github start to happen here, >> this mailing list will be just like the nuttx-commits mailing list. > > I'll take this as sarcasm. Sebastien is making a lot of valid points, > in good faith, and being dismissive does not help the community. >
Re: DISCUSSION - Usage of mailing lists for apache projects
If some PR waits for a long time without any review, how to make progress? For example, this PR sent two weaks ago: https://github.com/apache/nuttx/pull/8610 On Thu, Mar 9, 2023 at 4:40 PM alin.jerpe...@sony.com < alin.jerpe...@sony.com> wrote: > Hi all, > > I feel that this thread is getting too long without a real outcome > > Some observations from my daily interactions with the project: > - I like doing reviews on github and I think that many people in this > thread would agree that this flow is good. > - I like to be able to see all bugs in one place and get statistics for > the ASF reports > > What I don’t feel right > - even if I spend time daily on reviewing patches there are still changes > that I miss and it is hard to get the flow on release date > - some breaking changes are not discussed enough with the community since > there are some people that do not have time to review code on gihub. > > As a way going forward I propose that we improve in 2 aspects > - All breaking commits should be discusses on dev so that people get > enough time to digest the change and even better get involved int the flow > - all breaking changes should be documented on the release confluence page > before merging so that we don’t miss mentioning them on release date. > - there should be at least 1 independent reviewer (not from the same > company) so that a patch is merged except board changes (ex an employee > from the same company merges a patch submitted by another employee from the > same company, for a board provided by the same company) > > Thanks > Alin > > -Original Message- > From: Alan C. Assis > Sent: den 8 mars 2023 19:15 > To: dev@nuttx.apache.org > Cc: Sebastien Lorquet > Subject: Re: DISCUSSION - Usage of mailing lists for apache projects > > Hi Lwazi, > > It is not sarcarm, I'm talking about facts. > > Also I didn't say Sebastien points aren't valid, but is diverting from the > real issue. > > The issue is not if the discussion is happening here or there, the Problem > is that we don't have enough reviewers. > > So, first step is that NuttX needs to increase the user base, but have few > users really engaged with the project, reviewing patches every single day. > Currently today he have few: Petro and Xiang are exceptional on this point. > They are my inspiration to try do more! > > Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear > from you again! You have a great knowledge of BLE can we need! I was > expecting you to share that working example of BLE application using our > BLE stack). > > BR, > > Alan > > On 3/8/23, Lwazi Dube wrote: > > On Wed, 8 Mar 2023 at 09:55, Alan C. Assis wrote: > >> > >> Sebastien, > >> > >> If all the discussions that happens on github start to happen here, > >> this mailing list will be just like the nuttx-commits mailing list. > > > > I'll take this as sarcasm. Sebastien is making a lot of valid points, > > in good faith, and being dismissive does not help the community. > > >
RE: DISCUSSION - Usage of mailing lists for apache projects
I would add that all pull request must have a statement explaining the reason or motivation for the change(s). Just stating the "What" was done is not enough. There must be a "Why" the change is needed. David -Original Message- From: alin.jerpe...@sony.com Sent: Thursday, March 9, 2023 3:39 AM To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: RE: DISCUSSION - Usage of mailing lists for apache projects Hi all, I feel that this thread is getting too long without a real outcome Some observations from my daily interactions with the project: - I like doing reviews on github and I think that many people in this thread would agree that this flow is good. - I like to be able to see all bugs in one place and get statistics for the ASF reports What I don’t feel right - even if I spend time daily on reviewing patches there are still changes that I miss and it is hard to get the flow on release date - some breaking changes are not discussed enough with the community since there are some people that do not have time to review code on gihub. As a way going forward I propose that we improve in 2 aspects - All breaking commits should be discusses on dev so that people get enough time to digest the change and even better get involved int the flow - all breaking changes should be documented on the release confluence page before merging so that we don’t miss mentioning them on release date. - there should be at least 1 independent reviewer (not from the same company) so that a patch is merged except board changes (ex an employee from the same company merges a patch submitted by another employee from the same company, for a board provided by the same company) Thanks Alin -Original Message- From: Alan C. Assis Sent: den 8 mars 2023 19:15 To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: Re: DISCUSSION - Usage of mailing lists for apache projects Hi Lwazi, It is not sarcarm, I'm talking about facts. Also I didn't say Sebastien points aren't valid, but is diverting from the real issue. The issue is not if the discussion is happening here or there, the Problem is that we don't have enough reviewers. So, first step is that NuttX needs to increase the user base, but have few users really engaged with the project, reviewing patches every single day. Currently today he have few: Petro and Xiang are exceptional on this point. They are my inspiration to try do more! Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear from you again! You have a great knowledge of BLE can we need! I was expecting you to share that working example of BLE application using our BLE stack). BR, Alan On 3/8/23, Lwazi Dube wrote: > On Wed, 8 Mar 2023 at 09:55, Alan C. Assis wrote: >> >> Sebastien, >> >> If all the discussions that happens on github start to happen here, >> this mailing list will be just like the nuttx-commits mailing list. > > I'll take this as sarcasm. Sebastien is making a lot of valid points, > in good faith, and being dismissive does not help the community. >
Re: DISCUSSION - Usage of mailing lists for apache projects
Hi, Sounds like a good summary, and also a good improvement if implemented as described here and actually enforced. May I suggest just a bit more documentation than just official release notes? For example, warnings in commit messages, so we get no nasty surprise after an innocent git pull? Additionally, something should be indicated when usual apps will be categorically incompatible, if possible? Discussion about the status of the master branch is also interesting. how many breakage should we expect on this branch? Should that be a separate thread? Sebastien Le 09/03/2023 à 09:39, alin.jerpe...@sony.com a écrit : Hi all, I feel that this thread is getting too long without a real outcome Some observations from my daily interactions with the project: - I like doing reviews on github and I think that many people in this thread would agree that this flow is good. - I like to be able to see all bugs in one place and get statistics for the ASF reports What I don’t feel right - even if I spend time daily on reviewing patches there are still changes that I miss and it is hard to get the flow on release date - some breaking changes are not discussed enough with the community since there are some people that do not have time to review code on gihub. As a way going forward I propose that we improve in 2 aspects - All breaking commits should be discusses on dev so that people get enough time to digest the change and even better get involved int the flow - all breaking changes should be documented on the release confluence page before merging so that we don’t miss mentioning them on release date. - there should be at least 1 independent reviewer (not from the same company) so that a patch is merged except board changes (ex an employee from the same company merges a patch submitted by another employee from the same company, for a board provided by the same company) Thanks Alin -Original Message- From: Alan C. Assis Sent: den 8 mars 2023 19:15 To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: Re: DISCUSSION - Usage of mailing lists for apache projects Hi Lwazi, It is not sarcarm, I'm talking about facts. Also I didn't say Sebastien points aren't valid, but is diverting from the real issue. The issue is not if the discussion is happening here or there, the Problem is that we don't have enough reviewers. So, first step is that NuttX needs to increase the user base, but have few users really engaged with the project, reviewing patches every single day. Currently today he have few: Petro and Xiang are exceptional on this point. They are my inspiration to try do more! Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear from you again! You have a great knowledge of BLE can we need! I was expecting you to share that working example of BLE application using our BLE stack). BR, Alan On 3/8/23, Lwazi Dube wrote: On Wed, 8 Mar 2023 at 09:55, Alan C. Assis wrote: Sebastien, If all the discussions that happens on github start to happen here, this mailing list will be just like the nuttx-commits mailing list. I'll take this as sarcasm. Sebastien is making a lot of valid points, in good faith, and being dismissive does not help the community.
RE: DISCUSSION - Usage of mailing lists for apache projects
Hi all, I feel that this thread is getting too long without a real outcome Some observations from my daily interactions with the project: - I like doing reviews on github and I think that many people in this thread would agree that this flow is good. - I like to be able to see all bugs in one place and get statistics for the ASF reports What I don’t feel right - even if I spend time daily on reviewing patches there are still changes that I miss and it is hard to get the flow on release date - some breaking changes are not discussed enough with the community since there are some people that do not have time to review code on gihub. As a way going forward I propose that we improve in 2 aspects - All breaking commits should be discusses on dev so that people get enough time to digest the change and even better get involved int the flow - all breaking changes should be documented on the release confluence page before merging so that we don’t miss mentioning them on release date. - there should be at least 1 independent reviewer (not from the same company) so that a patch is merged except board changes (ex an employee from the same company merges a patch submitted by another employee from the same company, for a board provided by the same company) Thanks Alin -Original Message- From: Alan C. Assis Sent: den 8 mars 2023 19:15 To: dev@nuttx.apache.org Cc: Sebastien Lorquet Subject: Re: DISCUSSION - Usage of mailing lists for apache projects Hi Lwazi, It is not sarcarm, I'm talking about facts. Also I didn't say Sebastien points aren't valid, but is diverting from the real issue. The issue is not if the discussion is happening here or there, the Problem is that we don't have enough reviewers. So, first step is that NuttX needs to increase the user base, but have few users really engaged with the project, reviewing patches every single day. Currently today he have few: Petro and Xiang are exceptional on this point. They are my inspiration to try do more! Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear from you again! You have a great knowledge of BLE can we need! I was expecting you to share that working example of BLE application using our BLE stack). BR, Alan On 3/8/23, Lwazi Dube wrote: > On Wed, 8 Mar 2023 at 09:55, Alan C. Assis wrote: >> >> Sebastien, >> >> If all the discussions that happens on github start to happen here, >> this mailing list will be just like the nuttx-commits mailing list. > > I'll take this as sarcasm. Sebastien is making a lot of valid points, > in good faith, and being dismissive does not help the community. >
