RE: Release Notes for the NEXT version of NuttX
> -Original Message- > From: Abdelatif Guettouche > Sent: Saturday, May 23, 2020 9:18 PM > To: dev@nuttx.apache.org > Subject: Re: Release Notes for the NEXT version of NuttX > > > Yes, it's better to accumulative all patch for a specific release candidate > > in an issue/request in the future release, then we can track > each release more easier. > > Commit wise, we would have the same history, or are you suggesting to squash > all the backported commits? > No, the commit still separate as master, but we use one issue/pr track all cherry-picked patch for a release candidate. And to help track the history, only the critical bug fix get cherry-picked from master to release branch. > > On Sat, May 23, 2020 at 7:40 AM Xiang Xiao wrote: > > > > > > > > > -Original Message- > > > From: Nathan Hartman > > > Sent: Saturday, May 23, 2020 5:11 AM > > > To: dev@nuttx.apache.org > > > Subject: Re: Release Notes for the NEXT version of NuttX > > > > > > On Fri, May 22, 2020 at 4:54 PM Brennan Ashton > > > wrote: > > > > Nevermind I see what you were asking for. There is no great way to > > > > do this with git directly, usually you track this by using labels > > > > (or > > > > similar) on issues or PRs to aggregate it. At least that is that > > > > is how I have always run releases for work. > > > > > > Ugh, I don't think we've done that. At least, we haven't consistently. > > > > > > So, I'm guessing we'll have to take the log since that branch point, > > > but then manually exclude the commits that were cherry-picked to 9.0? > > > Sounds like a lot of effort. :-( > > > > > > > Yes, it's better to accumulative all patch for a specific release candidate > > in an issue/request in the future release, then we can track > each release more easier. > > > > > Nathan > >
Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
PR #1105 should eliminate the primary cause of the error: fs_fdopen() will not longer set the errno variable. The secondary error, the uninitialized stack description, is still a problem. Since the errno value was only set before fs_fdopen() failed, this means that you system will still not work. It should not crash but it should not work either. Now the fs_fdopen() calls will silently and mysteriously fail, perhaps with the only symptom being no standard I/O in the started tasks.
Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
PR #1105 should eliminate the primary cause of the error: fs_fdopen() will not longer set the errno variable. The secondary error, the uninitialized stack description, is still a problem. On 5/22/2020 10:19 PM, Gregory Nutt wrote: The new implementation of set_errno require all thread(include IDLE) initialize the stack related fields in tcb_s correctly. But many chipset forget to setup them for IDLE thread. TODO contain an item described this: ... snip ... Hello, I think there's a problem with set_errno() in nx_start(), when CONFIG_TLS_ALIGNED is not set: I disabled SERIAL_CONSOLE and DEV_CONSOLE, because I wanted to test CDCACM_CONSOLE. Now calling fs_fdopen() in group_setupstreams() leads to a call of set_errno(). In addition, nothing within the OS should ever set the errno value. So the first bug is the fs_fdopen() should not call set_errno(); It is a secondary problem that the stack data is not initialized. It should never be needed for the purpose errno access since no logic in the OS should ever access the errno. Greg
Re: Release Notes for the NEXT version of NuttX
> Yes, it's better to accumulative all patch for a specific release candidate > in an issue/request in the future release, then we can track each release > more easier. Commit wise, we would have the same history, or are you suggesting to squash all the backported commits? On Sat, May 23, 2020 at 7:40 AM Xiang Xiao wrote: > > > > > -Original Message- > > From: Nathan Hartman > > Sent: Saturday, May 23, 2020 5:11 AM > > To: dev@nuttx.apache.org > > Subject: Re: Release Notes for the NEXT version of NuttX > > > > On Fri, May 22, 2020 at 4:54 PM Brennan Ashton > > wrote: > > > Nevermind I see what you were asking for. There is no great way to do > > > this with git directly, usually you track this by using labels (or > > > similar) on issues or PRs to aggregate it. At least that is that is > > > how I have always run releases for work. > > > > Ugh, I don't think we've done that. At least, we haven't consistently. > > > > So, I'm guessing we'll have to take the log since that branch point, but > > then manually exclude the commits that were cherry-picked to > > 9.0? > > Sounds like a lot of effort. :-( > > > > Yes, it's better to accumulative all patch for a specific release candidate > in an issue/request in the future release, then we can track each release > more easier. > > > Nathan >
RE: Release Notes for the NEXT version of NuttX
> -Original Message- > From: Nathan Hartman > Sent: Saturday, May 23, 2020 5:11 AM > To: dev@nuttx.apache.org > Subject: Re: Release Notes for the NEXT version of NuttX > > On Fri, May 22, 2020 at 4:54 PM Brennan Ashton > wrote: > > Nevermind I see what you were asking for. There is no great way to do > > this with git directly, usually you track this by using labels (or > > similar) on issues or PRs to aggregate it. At least that is that is > > how I have always run releases for work. > > Ugh, I don't think we've done that. At least, we haven't consistently. > > So, I'm guessing we'll have to take the log since that branch point, but then > manually exclude the commits that were cherry-picked to > 9.0? > Sounds like a lot of effort. :-( > Yes, it's better to accumulative all patch for a specific release candidate in an issue/request in the future release, then we can track each release more easier. > Nathan
