> 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
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
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
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
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
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
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?
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,
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
Hi,
As I'm the person who usually generates a lot of "style related" comments I
want to reply as well.
Since GitHub does not have a "severity" option for the option it is not too
convenient to distinguish between "optional" with "must have" comments. So
usually I use the "Comment" button instead
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,
Hi,
Please don't take the following as a rant, but rather as a kind reminder
for people conducting code reviews for NuttX.
Please, respect the author. You don't need to re-write every line of the
patch in comments just because you feel that the variable name could be
different or something
12 matches
Mail list logo
