Re: NuttX github code review practices
Another example: https://github.com/apache/incubator-nuttx/pull/5731 A PR which looks like 0 gain, 100 risk of breaking everything (breaks our stuff at least), and can only work in FLAT_BUILD mode (if even in that?). How does stuff like this get in? Xiaomi does and approves by themselves? Sorry for being blunt, but this is really irritating. -Jukka On 25.3.2022 21.47, Xiang Xiao wrote: On Fri, Mar 25, 2022 at 6:53 PM Jukka Laitinen wrote: Hi, I was trying to make a more general statement than starting discussion on separate PRs, but let me shortly answer still On 25.3.2022 10.32, Xiang Xiao wrote: On Fri, Mar 25, 2022 at 3:35 PM Jukka Laitinen wrote: Hi, As an another example, we would very much like to bring in CONFIG_BUILD_KERNEL support for RISC-V for NuttX, as we have worked hard on this for some time, and have it working. Now, even when this work it is only additions, not breaking anything for FLAT_BUILD users, Yes, it doesn't break FLAT_BUILD, but doesn't mean KERNEL design or code is perfect, that's why the interesting people can give the comment. But of course! is stuck in endless debate where half of the comments show that the reviewer doesn't know the RISC-V ISA thoroughly, Sorry, I give you this impression, but I have worked on RiSCV since 2018:(. I wasn't referring to you with the above comment... and I am sorry about this. I'll try to avoid anything that can be interpreted as comments to person, in the future. and is referring to how things are done in ARM world. And the other half is largely useless style nitpicking. I think the most debate is about how S-mode talks with M-mode in this PR. The module design and standard compliant is always NuttX core value and highlight in: https://github.com/apache/incubator-nuttx/blob/master/INVIOLABLES.md Since OpenSBI is adopted by many OS to interact with M-mode firmware: https://github.com/riscv-software-src/opensbi It's always good to follow the best practice and what I insist in this PR: we can implement a minimal subset of OpenSBI to support S-mode NuttX, We (TII, it's research partners and subcontractors) will not be using OpenSBI for interfacing between S-mode and M-mode inside NuttX, since it doesn't make any sense for us. For running NuttX in kernel mode, we will not "implement a subset of OpenSBI". We (Ville) have implemented the "native SBI for NuttX". OpenSBI is not a standard, it is just a library maintained by a few people. It is much better to just do what is needed to do what is good for NuttX, following the standard RISC-V ISA spec, and not blindly go with a 3rd party bloated library. Ok, if you still prefer native SBI, please at least add a choice option in Kconfig, so other people can support OpenSBI later. but don't invent a private interface since M-mode firmware mayn't run NuttX at all. Now this is fair request, and I don't see any problems in implementing this also for the mpfs in the future. Currently that PR (IMHO) doesn't prevent having another M-mode firmware+any custom SBI such as OpenSBI on other platforms. Currently there are also parts under mpfs board, which can be generalized later on to avoid code copy paste, if others want to use our implementation on other risc-v archs. Right now there is no copy-paste code added, since this is not used in any other risc-v archs. I see bringing in CONFIG_BUILD_KERNEL as a very important step, and I see it a huge step forward if we can get in even one new architecture in supporting that. But putting too much pressure on making world perfect for the whole risc-v/nuttx community at once is just too much. Incremental steps forward is much better way... First make it work on one board, then generalize functionality when taking it into use in another and so on... Sure, but since it's a bigger change and the implementation is unique in many places, it's expected that the review process will be a bit longer. Anyhow, let's try to keep the discussion regarding a single PR within that PR in github. And I am really sorry if you felt that I was accusing you of something. it was not my intention. I truly appreciate that you are putting so much time and effort for reviewing patches to NuttX. Thanks, Jukka
Re: NuttX github code review practices
In this example it's Xiaomi and Sony. NuttX has a code review problem and it has to be identified and addressed. I have the same feeling here, last time I tried to send a pull request, it took several day to fix style issues for a ONE LINE code typo. And a lot of board breaking changes are committed regularly. when you have a custom board it's not fun. I believe a LOT of things including new features happens "silently" in github comments only, and very little is discussed on this mailing list. Sebastien Le 28/03/2022 à 11:30, Jukka Laitinen a écrit : Another example: https://github.com/apache/incubator-nuttx/pull/5731 A PR which looks like 0 gain, 100 risk of breaking everything (breaks our stuff at least), and can only work in FLAT_BUILD mode (if even in that?). How does stuff like this get in? Xiaomi does and approves by themselves? Sorry for being blunt, but this is really irritating. -Jukka On 25.3.2022 21.47, Xiang Xiao wrote: On Fri, Mar 25, 2022 at 6:53 PM Jukka Laitinen wrote: Hi, I was trying to make a more general statement than starting discussion on separate PRs, but let me shortly answer still On 25.3.2022 10.32, Xiang Xiao wrote: On Fri, Mar 25, 2022 at 3:35 PM Jukka Laitinen wrote: Hi, As an another example, we would very much like to bring in CONFIG_BUILD_KERNEL support for RISC-V for NuttX, as we have worked hard on this for some time, and have it working. Now, even when this work it is only additions, not breaking anything for FLAT_BUILD users, Yes, it doesn't break FLAT_BUILD, but doesn't mean KERNEL design or code is perfect, that's why the interesting people can give the comment. But of course! is stuck in endless debate where half of the comments show that the reviewer doesn't know the RISC-V ISA thoroughly, Sorry, I give you this impression, but I have worked on RiSCV since 2018:(. I wasn't referring to you with the above comment... and I am sorry about this. I'll try to avoid anything that can be interpreted as comments to person, in the future. and is referring to how things are done in ARM world. And the other half is largely useless style nitpicking. I think the most debate is about how S-mode talks with M-mode in this PR. The module design and standard compliant is always NuttX core value and highlight in: https://github.com/apache/incubator-nuttx/blob/master/INVIOLABLES.md Since OpenSBI is adopted by many OS to interact with M-mode firmware: https://github.com/riscv-software-src/opensbi It's always good to follow the best practice and what I insist in this PR: we can implement a minimal subset of OpenSBI to support S-mode NuttX, We (TII, it's research partners and subcontractors) will not be using OpenSBI for interfacing between S-mode and M-mode inside NuttX, since it doesn't make any sense for us. For running NuttX in kernel mode, we will not "implement a subset of OpenSBI". We (Ville) have implemented the "native SBI for NuttX". OpenSBI is not a standard, it is just a library maintained by a few people. It is much better to just do what is needed to do what is good for NuttX, following the standard RISC-V ISA spec, and not blindly go with a 3rd party bloated library. Ok, if you still prefer native SBI, please at least add a choice option in Kconfig, so other people can support OpenSBI later. but don't invent a private interface since M-mode firmware mayn't run NuttX at all. Now this is fair request, and I don't see any problems in implementing this also for the mpfs in the future. Currently that PR (IMHO) doesn't prevent having another M-mode firmware+any custom SBI such as OpenSBI on other platforms. Currently there are also parts under mpfs board, which can be generalized later on to avoid code copy paste, if others want to use our implementation on other risc-v archs. Right now there is no copy-paste code added, since this is not used in any other risc-v archs. I see bringing in CONFIG_BUILD_KERNEL as a very important step, and I see it a huge step forward if we can get in even one new architecture in supporting that. But putting too much pressure on making world perfect for the whole risc-v/nuttx community at once is just too much. Incremental steps forward is much better way... First make it work on one board, then generalize functionality when taking it into use in another and so on... Sure, but since it's a bigger change and the implementation is unique in many places, it's expected that the review process will be a bit longer. Anyhow, let's try to keep the discussion regarding a single PR within that PR in github. And I am really sorry if you felt that I was accusing you of something. it was not my intention. I truly appreciate that you are putting so much time and effort for reviewing patches to NuttX. Thanks, Jukka
Re: NuttX github code review practices
On Mon, Mar 28, 2022 at 5:30 PM Jukka Laitinen wrote: > Another example: > > https://github.com/apache/incubator-nuttx/pull/5731 > > A PR which looks like 0 gain, 100 risk of breaking everything (breaks > our stuff at least), This patch can improve the context switch performance, since it could avoid the follow memory copy in every context switch: 1. 32 integer register(128B on 32bit, 256B on 64bit) 2. 32 float register(128B single precision, 256B double precision) 3. Two status register And at the same time, each tcb can also reduce the same amount of memory. So, could you give more info why this change is zero gain? > and can only work in FLAT_BUILD mode (if even in > that?). > This patch should work fine for both flat and protected builds, both Xiaomi and Sony test on several boards. > > How does stuff like this get in? Xiaomi does and approves by themselves? > Sorry for being blunt, but this is really irritating. > > This patch is developed by Xiaomi, but reviewed, tested and merged by Sony. Normally, big changes like this will be reviewed by different groups and will be held at least several days before merging. Anyone could give the feedback on github and all comments must be addressed before merging. If you look at this patch closely: 1. This patch was created 15 days ago 2. And has more than 20 comments > -Jukka > > > On 25.3.2022 21.47, Xiang Xiao wrote: > > On Fri, Mar 25, 2022 at 6:53 PM Jukka Laitinen > > wrote: > > > >> Hi, > >> > >> I was trying to make a more general statement than starting discussion > >> on separate PRs, but let me shortly answer still > >> > >> On 25.3.2022 10.32, Xiang Xiao wrote: > >>> On Fri, Mar 25, 2022 at 3:35 PM Jukka Laitinen > >>> wrote: > >>> > Hi, > > > As an another example, we would very much like to bring in > CONFIG_BUILD_KERNEL support for RISC-V for NuttX, as we have worked > hard > on this for some time, and have it working. Now, even when this work > it > is only additions, not breaking anything for FLAT_BUILD users, > >>> Yes, it doesn't break FLAT_BUILD, but doesn't mean KERNEL design or > code > >> is > >>> perfect, that's why the interesting people can give the comment. > >> But of course! > is stuck > in endless debate where half of the comments show that the reviewer > doesn't know the RISC-V ISA thoroughly, > > > Sorry, I give you this impression, but I have worked on RiSCV since > >> 2018:(. > >> > >> I wasn't referring to you with the above comment... and I am sorry about > >> this. I'll try to avoid anything that can be interpreted as comments to > >> person, in the future. > >> > and is referring to how things > are done in ARM world. And the other half is largely useless style > nitpicking. > > >>> I think the most debate is about how S-mode talks with M-mode in this > PR. > >>> The module design and standard compliant is always NuttX core value and > >>> highlight in: > >>> https://github.com/apache/incubator-nuttx/blob/master/INVIOLABLES.md > >>> Since OpenSBI is adopted by many OS to interact with M-mode firmware: > >>> https://github.com/riscv-software-src/opensbi > >>> It's always good to follow the best practice and what I insist in this > >> PR: > >>> we can implement a minimal subset of OpenSBI to support S-mode NuttX, > >> We (TII, it's research partners and subcontractors) will not be using > >> OpenSBI for interfacing between S-mode and M-mode inside NuttX, since it > >> doesn't make any sense for us. For running NuttX in kernel mode, we will > >> not "implement a subset of OpenSBI". We (Ville) have implemented the > >> "native SBI for NuttX". OpenSBI is not a standard, it is just a library > >> maintained by a few people. It is much better to just do what is needed > >> to do what is good for NuttX, following the standard RISC-V ISA spec, > >> and not blindly go with a 3rd party bloated library. > >> > > Ok, if you still prefer native SBI, please at least add a choice option > in > > Kconfig, > > so other people can support OpenSBI later. > > > > > >>>but > >>> don't invent a private interface since M-mode firmware mayn't run NuttX > >> at > >>> all. > >> Now this is fair request, and I don't see any problems in implementing > >> this also for the mpfs in the future. Currently that PR (IMHO) doesn't > >> prevent having another M-mode firmware+any custom SBI such as OpenSBI on > >> other platforms. Currently there are also parts under mpfs board, which > >> can be generalized later on to avoid code copy paste, if others want to > >> use our implementation on other risc-v archs. Right now there is no > >> copy-paste code added, since this is not used in any other risc-v archs. > >> > >> I see bringing in CONFIG_BUILD_KERNEL as a very important step, and I > >> see it a huge step forward if we can get in even one new architecture in > >> supporting that. But putting too much pressure on making world perfect > >> f
Re: NuttX github code review practices
On Mon, Mar 28, 2022 at 6:02 PM Sebastien Lorquet wrote: > In this example it's Xiaomi and Sony. > > NuttX has a code review problem and it has to be identified and addressed. > The review strictly follows the process setup and agreed by the community, and the process is also similar to other Apache projects. But anyone could provide a better suggestion or workflow to improve the process. > > I have the same feeling here, last time I tried to send a pull request, > it took several day to fix style issues for a ONE LINE code typo. > Could you point out the PR? Most minor changes will be reviewed within one day I think. > > And a lot of board breaking changes are committed regularly. when you > have a custom board it's not fun. > Sorry for the inconvenience. But, sometime i > I believe a LOT of things including new features happens "silently" in > github comments only, Yes, that's because the agreed workflow is based on github. > and very little is discussed on this mailing list. > > Do you like the email based workflow like the Linux community? Since it's a fundamental change, it's better to start a new thread to discuss. > Sebastien > > > Le 28/03/2022 à 11:30, Jukka Laitinen a écrit : > > Another example: > > > > https://github.com/apache/incubator-nuttx/pull/5731 > > > > A PR which looks like 0 gain, 100 risk of breaking everything (breaks > > our stuff at least), and can only work in FLAT_BUILD mode (if even in > > that?). > > > > How does stuff like this get in? Xiaomi does and approves by > > themselves? Sorry for being blunt, but this is really irritating. > > > > -Jukka > > > > > > On 25.3.2022 21.47, Xiang Xiao wrote: > >> On Fri, Mar 25, 2022 at 6:53 PM Jukka Laitinen > >> wrote: > >> > >>> Hi, > >>> > >>> I was trying to make a more general statement than starting discussion > >>> on separate PRs, but let me shortly answer still > >>> > >>> On 25.3.2022 10.32, Xiang Xiao wrote: > On Fri, Mar 25, 2022 at 3:35 PM Jukka Laitinen > > wrote: > > > Hi, > > > > > > As an another example, we would very much like to bring in > > CONFIG_BUILD_KERNEL support for RISC-V for NuttX, as we have > > worked hard > > on this for some time, and have it working. Now, even when this > > work it > > is only additions, not breaking anything for FLAT_BUILD users, > Yes, it doesn't break FLAT_BUILD, but doesn't mean KERNEL design or > code > >>> is > perfect, that's why the interesting people can give the comment. > >>> But of course! > > is stuck > > in endless debate where half of the comments show that the reviewer > > doesn't know the RISC-V ISA thoroughly, > > > > > > Sorry, I give you this impression, but I have worked on RiSCV since > >>> 2018:(. > >>> > >>> I wasn't referring to you with the above comment... and I am sorry > >>> about > >>> this. I'll try to avoid anything that can be interpreted as comments to > >>> person, in the future. > >>> > > and is referring to how things > > are done in ARM world. And the other half is largely useless style > > nitpicking. > > > I think the most debate is about how S-mode talks with M-mode in > this PR. > The module design and standard compliant is always NuttX core value > and > highlight in: > https://github.com/apache/incubator-nuttx/blob/master/INVIOLABLES.md > Since OpenSBI is adopted by many OS to interact with M-mode firmware: > https://github.com/riscv-software-src/opensbi > It's always good to follow the best practice and what I insist in this > >>> PR: > we can implement a minimal subset of OpenSBI to support S-mode NuttX, > >>> We (TII, it's research partners and subcontractors) will not be using > >>> OpenSBI for interfacing between S-mode and M-mode inside NuttX, > >>> since it > >>> doesn't make any sense for us. For running NuttX in kernel mode, we > >>> will > >>> not "implement a subset of OpenSBI". We (Ville) have implemented the > >>> "native SBI for NuttX". OpenSBI is not a standard, it is just a library > >>> maintained by a few people. It is much better to just do what is needed > >>> to do what is good for NuttX, following the standard RISC-V ISA spec, > >>> and not blindly go with a 3rd party bloated library. > >>> > >> Ok, if you still prefer native SBI, please at least add a choice > >> option in > >> Kconfig, > >> so other people can support OpenSBI later. > >> > >> > but > don't invent a private interface since M-mode firmware mayn't run > NuttX > >>> at > all. > >>> Now this is fair request, and I don't see any problems in implementing > >>> this also for the mpfs in the future. Currently that PR (IMHO) doesn't > >>> prevent having another M-mode firmware+any custom SBI such as > >>> OpenSBI on > >>> other platforms. Currently there are also parts under mpfs board, which > >>> can be generalized later on to avoid code copy paste, if others want to
Re: NuttX github code review practices
On 3/28/22, Sebastien Lorquet wrote: > In this example it's Xiaomi and Sony. > > NuttX has a code review problem and it has to be identified and addressed. > > I have the same feeling here, last time I tried to send a pull request, > it took several day to fix style issues for a ONE LINE code typo. > Most probably you didn't follow the process to verify for code style errors etc: https://nuttx.apache.org/docs/latest/contributing/making-changes.html#git-workflow-with-an-upstream-repository > And a lot of board breaking changes are committed regularly. when you > have a custom board it's not fun. > Please help us to test! We don't have CI with a board farm test to help us. > I believe a LOT of things including new features happens "silently" in > github comments only, and very little is discussed on this mailing list. > This mailing list purpose it not for code reviewing, but you can subscribe on github or apache repository to receive an email with each PR and with each comment other people are doing. We need more people to review the code, not more people to complain! BR, Alan
RE: NuttX 10.3 release plan
Hi all, I am happy to announce the confluence release notes are ready and we can proceed with the NuttX 10.3-RC0 release @Nathan Hartman please check if you can fix the format https://cwiki.apache.org/confluence/display/NUTTX/NuttX+10.3 Does anyone oppose to the removal of the DISCLAIMER for 10.3-RC0 release ? Best regards Alin -Original Message- From: alin.jerpe...@sony.com Sent: den 17 mars 2022 09:33 To: dev@nuttx.apache.org; Nathan Hartman Subject: RE: NuttX 10.3 release plan @Nathan Hartman thanks for the update If you are ok with the current state for the Licensed please submit the PR for DISCLAIMER removal on both master and 10.3 branches Best regards Alin -Original Message- From: Nathan Hartman Sent: den 16 mars 2022 15:52 To: dev@nuttx.apache.org Subject: Re: NuttX 10.3 release plan On Wed, Mar 16, 2022 at 7:04 AM alin.jerpe...@sony.com wrote: > > Hi all, > > I created the release 10.3 branch and started working on the release > notes > > Please PR backports to the branch Thank you, Alin. Please note there is a draft Release Notes here: https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/NUTTX/NuttX*10.3__;Kw!!JmoZiZGBv3RvKRSx!os5eAPMXxcGPh3uu7kQuP3PAcPT5aESa_ARDPGyeOisZF7kXK_dUiDQA8VF4MrcmDA$ There I have documented "breaking changes" but not much else so far. I am looking forward to our first non-DISCLAIMER release and hopefully graduating soon afterwards! Cheers, Nathan
Re: NuttX github code review practices
Sorry, I cant possibly test every commit and tell you what breaks Have a few custom boards in the test process. we're talking build testing, not runtime. No need for a farm. I am not actively developing in nuttx. I'm just using it. Your request is ONLY possible for contributors working on NuttX full time on the very long term. It's not my situation. Following the github feeds would result in massive amounts of commit "spam" to read, sort, review, delete. sorry not possible given the amount of commits by certains companies and various topics. But still I see the project evolving with fear and tbh, because at some point I'll have to work on a new board (it's planned). I am not here to rant more. These were feelings and of course it's biased. I was just adding my voice to Jukka's concerns. Sebastien Le 28/03/2022 à 14:03, Alan Carvalho de Assis a écrit : On 3/28/22, Sebastien Lorquet wrote: In this example it's Xiaomi and Sony. NuttX has a code review problem and it has to be identified and addressed. I have the same feeling here, last time I tried to send a pull request, it took several day to fix style issues for a ONE LINE code typo. Most probably you didn't follow the process to verify for code style errors etc: https://nuttx.apache.org/docs/latest/contributing/making-changes.html#git-workflow-with-an-upstream-repository And a lot of board breaking changes are committed regularly. when you have a custom board it's not fun. Please help us to test! We don't have CI with a board farm test to help us. I believe a LOT of things including new features happens "silently" in github comments only, and very little is discussed on this mailing list. This mailing list purpose it not for code reviewing, but you can subscribe on github or apache repository to receive an email with each PR and with each comment other people are doing. We need more people to review the code, not more people to complain! BR, Alan
Re: usleep can't wake up incidentally in tickless mode
Hi Alan, I'm tried enable the CONFIG_PRIORITY_INHERITANCE and the problem remains, thanks for your reply Best regard Zou -- Original -- From: "Alan Carvalho de Assis"
Re: NuttX 10.3 release plan
I am OK with removing the disclaimer for 10.3. Thank you for your work on this, Alin! On Mon, Mar 28, 2022 at 2:32 PM alin.jerpe...@sony.com wrote: > > Hi all, > > I am happy to announce the confluence release notes are ready and we can > proceed with the NuttX 10.3-RC0 release > > @Nathan Hartman please check if you can fix the format > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+10.3 > > Does anyone oppose to the removal of the DISCLAIMER for 10.3-RC0 release ? > > Best regards > Alin > > > -Original Message- > From: alin.jerpe...@sony.com > Sent: den 17 mars 2022 09:33 > To: dev@nuttx.apache.org; Nathan Hartman > Subject: RE: NuttX 10.3 release plan > > @Nathan Hartman thanks for the update > > If you are ok with the current state for the Licensed please submit the PR > for DISCLAIMER removal on both master and 10.3 branches > > Best regards > Alin > > -Original Message- > From: Nathan Hartman > Sent: den 16 mars 2022 15:52 > To: dev@nuttx.apache.org > Subject: Re: NuttX 10.3 release plan > > On Wed, Mar 16, 2022 at 7:04 AM alin.jerpe...@sony.com > wrote: > > > > Hi all, > > > > I created the release 10.3 branch and started working on the release > > notes > > > > Please PR backports to the branch > > Thank you, Alin. Please note there is a draft Release Notes here: > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/NUTTX/NuttX*10.3__;Kw!!JmoZiZGBv3RvKRSx!os5eAPMXxcGPh3uu7kQuP3PAcPT5aESa_ARDPGyeOisZF7kXK_dUiDQA8VF4MrcmDA$ > > There I have documented "breaking changes" but not much else so far. > > I am looking forward to our first non-DISCLAIMER release and hopefully > graduating soon afterwards! > > Cheers, > Nathan
Re: NuttX github code review practices
> Have a few custom boards in the test process. we're talking build > testing, not runtime. No need for a farm. We actually should do this. It should be possible to have a few custom boards in another repository (the old testing repo for instance) and trigger its workflow on PRs. I believe once Greg suggested to use a special sim config with the necessary custom options enabled, if that work that would be simpler. However, I'm not sure if we can test all the possible configurations like this, for example we have boards with common folder, boards with no common folder and boards with common but the user doesn't want the common folder. Either way, we should do something about custom boards to avoid any breakage. Regarding testing in hardware, what we have right now is different organisations doing their own tests on their own infrastructure. In most cases, this means that we wait until the change is already in master. For us (as in Espressif) we sometimes push branches internally with the changes of some PRs that we think require more tests. I don't know how we can setup hardware test runners with Apache infrastructure, the best thing we can do is to have QEMU for most chips. This is a bit out of topic, sorry about this Jukka, we can move this discussion to a different thread if you want. Regarding code review, please remember that _anyone_ in the community can participate, it doesn't have to be a commiter or PPMC member. If a concern is raised by anyone, the corresponding PR will have to wait until everything is addressed. So if you guys have some spare time, you can check PRs of interest, you don't have to go through all the commits of all the PRs, any help is appreciated. On Mon, Mar 28, 2022 at 2:51 PM Sebastien Lorquet wrote: > > Sorry, I cant possibly test every commit and tell you what breaks > > Have a few custom boards in the test process. we're talking build > testing, not runtime. No need for a farm. > > I am not actively developing in nuttx. I'm just using it. > > > Your request is ONLY possible for contributors working on NuttX full > time on the very long term. > > It's not my situation. Following the github feeds would result in > massive amounts of commit "spam" to read, sort, review, delete. sorry > not possible given the amount of commits by certains companies and > various topics. > > But still I see the project evolving with fear and tbh, because at some > point I'll have to work on a new board (it's planned). > > > I am not here to rant more. These were feelings and of course it's > biased. I was just adding my voice to Jukka's concerns. > > > Sebastien > > > > > Le 28/03/2022 à 14:03, Alan Carvalho de Assis a écrit : > > On 3/28/22, Sebastien Lorquet wrote: > >> In this example it's Xiaomi and Sony. > >> > >> NuttX has a code review problem and it has to be identified and addressed. > >> > >> I have the same feeling here, last time I tried to send a pull request, > >> it took several day to fix style issues for a ONE LINE code typo. > >> > > Most probably you didn't follow the process to verify for code style errors > > etc: > > https://nuttx.apache.org/docs/latest/contributing/making-changes.html#git-workflow-with-an-upstream-repository > > > >> And a lot of board breaking changes are committed regularly. when you > >> have a custom board it's not fun. > >> > > Please help us to test! We don't have CI with a board farm test to help us. > > > >> I believe a LOT of things including new features happens "silently" in > >> github comments only, and very little is discussed on this mailing list. > >> > > This mailing list purpose it not for code reviewing, but you can > > subscribe on github or apache repository to receive an email with each > > PR and with each comment other people are doing. > > > > We need more people to review the code, not more people to complain! > > > > BR, > > > > Alan
Re: NuttX 10.3 release plan
On Mon, Mar 28, 2022 at 8:32 AM alin.jerpe...@sony.com < alin.jerpe...@sony.com> wrote: > > @Nathan Hartman please check if you can fix the format > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+10.3 > Hi Alin, What needs to be fixed? Cheers Nathan > >
