RE: [EXT] Re: NuttX Wiki Porting Guide SocketCAN addition
I've now got an approved account however it seems that the NuttX porting guide page is a read-only html page. Can this page be converted to Confluence/Wiki markup or is there a way for me to access this html file? Yours sincerely, Peter van der Perk peter.vanderp...@nxp.com -Original Message- From: Brennan Ashton Sent: 15 June, 2020 20:15 To: dev@nuttx.apache.org Subject: [EXT] Re: NuttX Wiki Porting Guide SocketCAN addition Caution: EXT Email On Mon, Jun 15, 2020 at 10:40 AM Peter Van Der Perk wrote: > > Thanks to the feedback of Gregory Nutt and Alan Carvalho de Assis today we > finally merged the SocketCAN code into NuttX. I've already made a porting > guide in the past > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpetervanderperk.nl%2Fnuttx_socketcan_porting_guide.pdf&data=02%7C01%7Cpeter.vanderperk%40nxp.com%7C900955770b694ac507e908d81158122d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637278417237452545&sdata=mxeyU2FjpP91XeHrd4JIBv4iidok%2B31aCfPZOLvn%2BO0%3D&reserved=0 > what's the procedure to get this documentation into the NuttX wiki Porting > guide? Peter, Thanks for all the work getting this feature in. As for the porting guide/wiki if you can send me your apache ID from registering on the wiki, I will happily approve your account for write access to the wiki. The extra step is just to keep the spam under control. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Flogin.action%3Fos_destination%3D%252Fdisplay%252FNUTTX%252FNuttx&data=02%7C01%7Cpeter.vanderperk%40nxp.com%7C900955770b694ac507e908d81158122d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637278417237452545&sdata=scc9iY%2B7MwXR1fzsMjmMkCXQvU41WWyV9zQsze0vdbY%3D&reserved=0 --Brennan
Re: SAMA5D27 SDMMC support branch
SDMMC DMA read is working now too. I'll work on DMA write next. -adam On Fri, Jun 12, 2020 at 2:45 PM Adam Feuer wrote: > I got the SDMMC write to work as well. This is in non-DMA mode. I'm going > to work on the DMA mode next. > > -adam > -- > Adam Feuer > -- Adam Feuer
Re: release branches/tags
On Mon, Jun 15, 2020 at 1:21 PM Matias N. wrote: > > The fact the the release branch was merged does not impede to continue to add > commits to it. In any case, I would expect fixes to LTS releases to bump the > version number, so whenever a new minor version for that LTS version is to be > released and it is considered final (i.e. 9.2 if 9.x is LTS), it would be > merged and tagged. > > Or am I missing something? > I am fairly sure you cannot do what you are asking and this is one of the points people bring up against the GitFlow workflow. Master cannot look like this: * - V-1.0.0 | - C1 | - C2 * - V-1.1.0 | - C3 * - V-1.0.1 (Bug fix to the V1.0 release) | - C4 This is why I recommended that you create a branch off of whatever release you are using and then use the rebase from the base from the tag to the head of your branch on to master or wherever you want Something like this: git rebase --onto nuttx-1.2 nuttx-1.0 HEAD --Brennan
Re: release branches/tags
The fact the the release branch was merged does not impede to continue to add commits to it. In any case, I would expect fixes to LTS releases to bump the version number, so whenever a new minor version for that LTS version is to be released and it is considered final (i.e. 9.2 if 9.x is LTS), it would be merged and tagged. Or am I missing something? On Mon, Jun 15, 2020, at 16:49, Nathan Hartman wrote: > On Mon, Jun 15, 2020 at 3:41 PM Matias N. wrote: > > > Functionally, yes. But git has troubles recognizing that the cherry-picked > > commits are the same on master and generates conflicts. The merge would > > solve this in theory, since the release branch tip would end up matching a > > commit on master. > > > Suppose in the future we wish to have LTS releases -- Long Term Support, > where "Support" just means that the release line receives bugfix and > security fix maintenance for a longer period of time than regular releases. > We briefly touched on this idea recently but are not ready to do it yet. > Nevertheless, as an example only for illustration, suppose that an LTS > release is to be maintained for 2 years. > > Then, how does the strategy of merging release branches back to master > support that type of requirement? > > Nathan >
what to do about this to make nxstyle happy?
https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/stm32l4/stm32l4_serial.c#L869 This file has multiple occurrences of this kind of ASCII art and it exceeds the 80th column.
Re: release branches/tags
On Mon, Jun 15, 2020 at 3:41 PM Matias N. wrote: > Functionally, yes. But git has troubles recognizing that the cherry-picked > commits are the same on master and generates conflicts. The merge would > solve this in theory, since the release branch tip would end up matching a > commit on master. Suppose in the future we wish to have LTS releases -- Long Term Support, where "Support" just means that the release line receives bugfix and security fix maintenance for a longer period of time than regular releases. We briefly touched on this idea recently but are not ready to do it yet. Nevertheless, as an example only for illustration, suppose that an LTS release is to be maintained for 2 years. Then, how does the strategy of merging release branches back to master support that type of requirement? Nathan
Re: release branches/tags
Functionally, yes. But git has troubles recognizing that the cherry-picked commits are the same on master and generates conflicts. The merge would solve this in theory, since the release branch tip would end up matching a commit on master. On Mon, Jun 15, 2020, at 16:31, Abdelatif Guettouche wrote: > The release branch doesn't contain anything that's not already present > in master. The log between the two branches (a release and master) > are just the cherry picked commits. So there is nothing really to > merge back. > > > On Mon, Jun 15, 2020 at 7:13 PM Matias N. wrote: > > > > As a reference, this merging back is used in GitFlow, so I guess it should > > work: > > https://datasift.github.io/gitflow/IntroducingGitFlow.html > > (see 4th figure) > > > > On Mon, Jun 15, 2020, at 15:09, Matias N. wrote: > > > On Mon, Jun 15, 2020, at 15:04, Brennan Ashton wrote: > > >> On Mon, Jun 15, 2020 at 10:47 AM Matias N. wrote: > > >> > > > >> > There are release tags created: > > >> > > https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.0.0-RC1 > > >> > > > >> > I understood that as a release candidate, not a final release. Anyway, > > >> > this just points to the tip of release/9.0 so it does not change my > > >> > situation. > > >> > > > >> Sorry, this is my oversight, I probably should have tagged that commit > > >> at nuttx-9.0.0 as well once it was approved by IPMC for release. I > > >> will create a signed tag this evening for both os and app, but yes the > > >> latest RC is the actual release. A bug fix release would be seen as a > > >> tag on the same branch with the patch number increased. The reason to > > >> rely on the tag and not the tip, is that any bug fix commit for a > > >> patch release would also go here and have that same multi-week window > > >> before it is released. > > > > > > No problem! > > > > > >> > > > >> > The ability to correct bugs after a release without having to also > > >> > include features that were added in between is understandable. But I > > >> > don't really understand why that does not allow to merge the release > > >> > branch back to master once it is considered final. Unless I'm mistaken > > >> > this should not create conflicts and would only "close the loop" and > > >> > let git later now how to deal with rebases between final release > > >> > points easily. > > >> > > > >> > > >> We can certainly give it a go on a temporary branch for this next > > >> release and see if that makes for a better workflow and if so apply > > >> the merge to master. We have been trying to only do fast-forward > > >> merges, but this might be worthy of an exception to that. > > > > > > Cool. It is good to test on a temporary branch and see if the idea works. > > > It would make upgrading between nuttx releases an easier process. > > > > > >> --Brennan > > >> > > > >
Re: release branches/tags
The release branch doesn't contain anything that's not already present in master. The log between the two branches (a release and master) are just the cherry picked commits. So there is nothing really to merge back. On Mon, Jun 15, 2020 at 7:13 PM Matias N. wrote: > > As a reference, this merging back is used in GitFlow, so I guess it should > work: > https://datasift.github.io/gitflow/IntroducingGitFlow.html > (see 4th figure) > > On Mon, Jun 15, 2020, at 15:09, Matias N. wrote: > > On Mon, Jun 15, 2020, at 15:04, Brennan Ashton wrote: > >> On Mon, Jun 15, 2020 at 10:47 AM Matias N. wrote: > >> > > >> > There are release tags created: > >> > > https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.0.0-RC1 > >> > > >> > I understood that as a release candidate, not a final release. Anyway, > >> > this just points to the tip of release/9.0 so it does not change my > >> > situation. > >> > > >> Sorry, this is my oversight, I probably should have tagged that commit > >> at nuttx-9.0.0 as well once it was approved by IPMC for release. I > >> will create a signed tag this evening for both os and app, but yes the > >> latest RC is the actual release. A bug fix release would be seen as a > >> tag on the same branch with the patch number increased. The reason to > >> rely on the tag and not the tip, is that any bug fix commit for a > >> patch release would also go here and have that same multi-week window > >> before it is released. > > > > No problem! > > > >> > > >> > The ability to correct bugs after a release without having to also > >> > include features that were added in between is understandable. But I > >> > don't really understand why that does not allow to merge the release > >> > branch back to master once it is considered final. Unless I'm mistaken > >> > this should not create conflicts and would only "close the loop" and let > >> > git later now how to deal with rebases between final release points > >> > easily. > >> > > >> > >> We can certainly give it a go on a temporary branch for this next > >> release and see if that makes for a better workflow and if so apply > >> the merge to master. We have been trying to only do fast-forward > >> merges, but this might be worthy of an exception to that. > > > > Cool. It is good to test on a temporary branch and see if the idea works. > > It would make upgrading between nuttx releases an easier process. > > > >> --Brennan > >> > >
Re: NuttX Wiki Porting Guide SocketCAN addition
On Mon, Jun 15, 2020 at 10:40 AM Peter Van Der Perk wrote: > > Thanks to the feedback of Gregory Nutt and Alan Carvalho de Assis today we > finally merged the SocketCAN code into NuttX. I've already made a porting > guide in the past > https://petervanderperk.nl/nuttx_socketcan_porting_guide.pdf what's the > procedure to get this documentation into the NuttX wiki Porting guide? Peter, Thanks for all the work getting this feature in. As for the porting guide/wiki if you can send me your apache ID from registering on the wiki, I will happily approve your account for write access to the wiki. The extra step is just to keep the spam under control. https://cwiki.apache.org/confluence/login.action?os_destination=%2Fdisplay%2FNUTTX%2FNuttx --Brennan
Re: release branches/tags
As a reference, this merging back is used in GitFlow, so I guess it should work: https://datasift.github.io/gitflow/IntroducingGitFlow.html (see 4th figure) On Mon, Jun 15, 2020, at 15:09, Matias N. wrote: > On Mon, Jun 15, 2020, at 15:04, Brennan Ashton wrote: >> On Mon, Jun 15, 2020 at 10:47 AM Matias N. wrote: >> > >> > There are release tags created: >> > > https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.0.0-RC1 >> > >> > I understood that as a release candidate, not a final release. Anyway, >> > this just points to the tip of release/9.0 so it does not change my >> > situation. >> > >> Sorry, this is my oversight, I probably should have tagged that commit >> at nuttx-9.0.0 as well once it was approved by IPMC for release. I >> will create a signed tag this evening for both os and app, but yes the >> latest RC is the actual release. A bug fix release would be seen as a >> tag on the same branch with the patch number increased. The reason to >> rely on the tag and not the tip, is that any bug fix commit for a >> patch release would also go here and have that same multi-week window >> before it is released. > > No problem! > >> > >> > The ability to correct bugs after a release without having to also include >> > features that were added in between is understandable. But I don't really >> > understand why that does not allow to merge the release branch back to >> > master once it is considered final. Unless I'm mistaken this should not >> > create conflicts and would only "close the loop" and let git later now how >> > to deal with rebases between final release points easily. >> > >> >> We can certainly give it a go on a temporary branch for this next >> release and see if that makes for a better workflow and if so apply >> the merge to master. We have been trying to only do fast-forward >> merges, but this might be worthy of an exception to that. > > Cool. It is good to test on a temporary branch and see if the idea works. It > would make upgrading between nuttx releases an easier process. > >> --Brennan >> >
Re: NuttX Wiki Porting Guide SocketCAN addition
On Mon, Jun 15, 2020 at 10:40 AM Peter Van Der Perk wrote: > > Thanks to the feedback of Gregory Nutt and Alan Carvalho de Assis today we > finally merged the SocketCAN code into NuttX. I've already made a porting > guide in the past > https://petervanderperk.nl/nuttx_socketcan_porting_guide.pdf what's the > procedure to get this documentation into the NuttX wiki Porting guide? Peter, Thanks for
Re: release branches/tags
On Mon, Jun 15, 2020, at 15:04, Brennan Ashton wrote: > On Mon, Jun 15, 2020 at 10:47 AM Matias N. wrote: > > > > There are release tags created: > > > https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.0.0-RC1 > > > > I understood that as a release candidate, not a final release. Anyway, this > > just points to the tip of release/9.0 so it does not change my situation. > > > Sorry, this is my oversight, I probably should have tagged that commit > at nuttx-9.0.0 as well once it was approved by IPMC for release. I > will create a signed tag this evening for both os and app, but yes the > latest RC is the actual release. A bug fix release would be seen as a > tag on the same branch with the patch number increased. The reason to > rely on the tag and not the tip, is that any bug fix commit for a > patch release would also go here and have that same multi-week window > before it is released. No problem! > > > > The ability to correct bugs after a release without having to also include > > features that were added in between is understandable. But I don't really > > understand why that does not allow to merge the release branch back to > > master once it is considered final. Unless I'm mistaken this should not > > create conflicts and would only "close the loop" and let git later now how > > to deal with rebases between final release points easily. > > > > We can certainly give it a go on a temporary branch for this next > release and see if that makes for a better workflow and if so apply > the merge to master. We have been trying to only do fast-forward > merges, but this might be worthy of an exception to that. Cool. It is good to test on a temporary branch and see if the idea works. It would make upgrading between nuttx releases an easier process. > --Brennan >
Re: release branches/tags
On Mon, Jun 15, 2020 at 10:47 AM Matias N. wrote: > > There are release tags created: > > https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.0.0-RC1 > > I understood that as a release candidate, not a final release. Anyway, this > just points to the tip of release/9.0 so it does not change my situation. > Sorry, this is my oversight, I probably should have tagged that commit at nuttx-9.0.0 as well once it was approved by IPMC for release. I will create a signed tag this evening for both os and app, but yes the latest RC is the actual release. A bug fix release would be seen as a tag on the same branch with the patch number increased. The reason to rely on the tag and not the tip, is that any bug fix commit for a patch release would also go here and have that same multi-week window before it is released. > > The ability to correct bugs after a release without having to also include > features that were added in between is understandable. But I don't really > understand why that does not allow to merge the release branch back to master > once it is considered final. Unless I'm mistaken this should not create > conflicts and would only "close the loop" and let git later now how to deal > with rebases between final release points easily. > We can certainly give it a go on a temporary branch for this next release and see if that makes for a better workflow and if so apply the merge to master. We have been trying to only do fast-forward merges, but this might be worthy of an exception to that. --Brennan
Re: release branches/tags
There are release tags created: > https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.0.0-RC1 I understood that as a release candidate, not a final release. Anyway, this just points to the tip of release/9.0 so it does not change my situation. > > > > I'm wondering if maybe there's something I could change in my workflow or > > maybe the release branching/tagging strategy could be adapted to ease > > downstream work. For example, if there would be something as a > > feature-freeze window some time before a release, disruptive PRs (ie: non > > bug fix PRs) against master could be held until master is stabilized and > > released with a tag. In this scenario I think release branches are not > > needed, the resulting history is linear and there are no unmerged tips. > > The last release was probably not a good indicator of how far the > release branch will deviate (there were a lot of backported fixes). > But part of the reason it is not feasible to just merge back in is two > fold: > 1. We want to have these branches for bug fix releases. The last > release did not have one, but there likely should have been one for at > least one bug that was found related to loading binaries > 2. With the Apache release process it takes a long time for releases > to get out the door. Once a RC is created it is likely 1-2 weeks > before it is actually released. There are two three day voting periods > and for example the last release one of those voting periods took a > week. We also had to do 2 release candidates each time we do that the > clock gets reset. In the mean time a lot of changes are happening in > master, even today just after the release branch was created a lot of > large changes went into master. The ability to correct bugs after a release without having to also include features that were added in between is understandable. But I don't really understand why that does not allow to merge the release branch back to master once it is considered final. Unless I'm mistaken this should not create conflicts and would only "close the loop" and let git later now how to deal with rebases between final release points easily. Going back to the alternative workflow of the feature-freeze window, you could also work on a separate "staging branch" instead of on master until a release is deemed final, where all disruptive PRs are collected. Then, once the latest release is deemed final, you can safely merge staging to master. In any case, what I suggested (regardless of the chosen workflow) is to not leave unmerged branches. > > What I suspect would actually work well is to change your rebase > strategy to instead of rebasing your entire branch (off of release > branch), but instead to rebase only your commits onto master or the > next release branch: > git rebase --onto dest first_commit last_commit > > With this you would exclude all of the backport commits which are > likely the source of the rebase troubles. > > I hope that helps. > > --Brennan > I guess that would work. It is a bit more painful and manual but I guess I will try that next time if release branches stay unmerged. Thanks for the suggestion. Best, Matias
NuttX Wiki Porting Guide SocketCAN addition
Thanks to the feedback of Gregory Nutt and Alan Carvalho de Assis today we finally merged the SocketCAN code into NuttX. I've already made a porting guide in the past https://petervanderperk.nl/nuttx_socketcan_porting_guide.pdf what's the procedure to get this documentation into the NuttX wiki Porting guide? Yours sincerely, Peter van der Perk
Re: release branches/tags
On Mon, Jun 15, 2020 at 9:55 AM Matias N. wrote: > > Hi, > I wanted to ask about what you think is the best way of working with > nuttx/apps repo for a downstream user considering the new release branching > strategy. > > Previously I was used to having the master branch contain release tags so I > would generally work on top of these tags creating local commits on my > project specific branch, inside a fork of nuttx/apps, if needed. Then, > whenever a new version of NuttX was released, I could rebase my branch to the > new release tag. Moreover, this local branch will usually contain a series of > commits which I intend to upstream (fixes/improvements). To do so, I would > create a branch stemming from master (or, at least, the most recent release > tag) and then cherry-pick these commits there. > To contribute this in the form of PRs I would do this creating one branch for > each PR. At the end of each PR acceptance I can then rebase my main working > branch to the new tip and the rebase would recognize these upstreamed commits > and would not generate any conflicts. In the end, my branch would only > contain non-upstreamed commits. > > Now, I'm facing a problem whereas I would like to work on top of stable > releases but since these are tips of branches that are never merged back to > master, rebasing as previously described introduces many conflicts between > commits which are backported from master to these branches. To me it is > strange that these release branches are never merged and no release tag seems > to exist. Most projects I worked with usually tag release commits and they > are always part of the main history. There are release tags created: https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.0.0-RC1 > > I'm wondering if maybe there's something I could change in my workflow or > maybe the release branching/tagging strategy could be adapted to ease > downstream work. For example, if there would be something as a feature-freeze > window some time before a release, disruptive PRs (ie: non bug fix PRs) > against master could be held until master is stabilized and released with a > tag. In this scenario I think release branches are not needed, the resulting > history is linear and there are no unmerged tips. The last release was probably not a good indicator of how far the release branch will deviate (there were a lot of backported fixes). But part of the reason it is not feasible to just merge back in is two fold: 1. We want to have these branches for bug fix releases. The last release did not have one, but there likely should have been one for at least one bug that was found related to loading binaries 2. With the Apache release process it takes a long time for releases to get out the door. Once a RC is created it is likely 1-2 weeks before it is actually released. There are two three day voting periods and for example the last release one of those voting periods took a week. We also had to do 2 release candidates each time we do that the clock gets reset. In the mean time a lot of changes are happening in master, even today just after the release branch was created a lot of large changes went into master. What I suspect would actually work well is to change your rebase strategy to instead of rebasing your entire branch (off of release branch), but instead to rebase only your commits onto master or the next release branch: git rebase --onto dest first_commit last_commit With this you would exclude all of the backport commits which are likely the source of the rebase troubles. I hope that helps. --Brennan
release branches/tags
Hi, I wanted to ask about what you think is the best way of working with nuttx/apps repo for a downstream user considering the new release branching strategy. Previously I was used to having the master branch contain release tags so I would generally work on top of these tags creating local commits on my project specific branch, inside a fork of nuttx/apps, if needed. Then, whenever a new version of NuttX was released, I could rebase my branch to the new release tag. Moreover, this local branch will usually contain a series of commits which I intend to upstream (fixes/improvements). To do so, I would create a branch stemming from master (or, at least, the most recent release tag) and then cherry-pick these commits there. To contribute this in the form of PRs I would do this creating one branch for each PR. At the end of each PR acceptance I can then rebase my main working branch to the new tip and the rebase would recognize these upstreamed commits and would not generate any conflicts. In the end, my branch would only contain non-upstreamed commits. Now, I'm facing a problem whereas I would like to work on top of stable releases but since these are tips of branches that are never merged back to master, rebasing as previously described introduces many conflicts between commits which are backported from master to these branches. To me it is strange that these release branches are never merged and no release tag seems to exist. Most projects I worked with usually tag release commits and they are always part of the main history. I'm wondering if maybe there's something I could change in my workflow or maybe the release branching/tagging strategy could be adapted to ease downstream work. For example, if there would be something as a feature-freeze window some time before a release, disruptive PRs (ie: non bug fix PRs) against master could be held until master is stabilized and released with a tag. In this scenario I think release branches are not needed, the resulting history is linear and there are no unmerged tips. Best, Matias
Re: Release 9.1
On Mon, Jun 15, 2020, 9:14 AM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > Thanks Nathan, > > > if there's anything else to add to the 9.1 release notes, that page > > remains here: > > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1 > > I think there is one PR in nuttx/ that's not included in the release > notes and maybe two in apps/. That should be quick. > Another thing left to do is to update the release note document in the > repo and all the relevant files under Documentation/. > Abdelatif, Thanks for creating the branches, I was not going to be able to get to it until after work today, so it's good to unblock the queue of PRs for master. Nathan, I will create new tracking projects for the 9.2 this evening for the projects. I think it will be a lot easier having this rolling from the start of the cycle. Thanks for getting the template up.
Re: Release 9.1
Thanks Nathan, > if there's anything else to add to the 9.1 release notes, that page > remains here: > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1 I think there is one PR in nuttx/ that's not included in the release notes and maybe two in apps/. That should be quick. Another thing left to do is to update the release note document in the repo and all the relevant files under Documentation/. On Mon, Jun 15, 2020 at 3:39 PM Nathan Hartman wrote: > > On Mon, Jun 15, 2020 at 8:58 AM Abdelatif Guettouche > wrote: > > Hi all, > > > > D-Day; I'll go ahead and create the branches. > > Thank you! > > I went ahead and created a blank release notes wiki for the *next* > release, 9.2, here: > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.2 > > If there's anything else to add to the 9.1 release notes, that page > remains here: > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1 > > Cheers, > Nathan
Re: Release 9.1
On Mon, Jun 15, 2020 at 8:58 AM Abdelatif Guettouche wrote: > Hi all, > > D-Day; I'll go ahead and create the branches. Thank you! I went ahead and created a blank release notes wiki for the *next* release, 9.2, here: https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.2 If there's anything else to add to the 9.1 release notes, that page remains here: https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1 Cheers, Nathan
Re: Release 9.1
Hi all, D-Day; I'll go ahead and create the branches. On Tue, Jun 9, 2020 at 2:42 PM Abdelatif Guettouche wrote: > > > I guess the other question I want to know is what is on master that is not > > in the release? > > There are some git log options that we can use to get that. What we > want is to just filter out the cherry-picked commits. > I shared this command before: "git log --oneline --cherry-pick > --right-only releases/9.0...master" > > > On Tue, Jun 9, 2020 at 1:32 PM David Sidrane wrote: > > > > I was speaking of git tag, for convenience. > > > > I guess the other question I want to know is what is on master that is not > > in the release? > > > > If we use git tags: One is dropped on the branch point. One is dropped on > > the release point. The delta on master is the full set of commits that came > > in to master while the release was happening. The delta (tag to HEAD) on the > > release branch is the backports, That will answer the question what is on > > master that is not in the release. > > > > With tags, commit message do not need to say [BACKPORT]. But if they do say > > [BACKPORT], all that is needed it the log to know what we back ported. > > > > I think one giant PR is harder to work with. Many BP PR's is fine just, > > titled or git labeled as a back port to release r.m.n would be helpful. If > > it is in the Title it will help filter emails. Not sure if the labels are > > helpful in an inbox but are on Github. > > > > Assuming master has testing, bug fix Backport PR should be merged with 0 > > delay. > > > > > > David > > > > -Original Message- > > From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com] > > Sent: Tuesday, June 09, 2020 5:02 AM > > To: dev@nuttx.apache.org > > Subject: Re: Release 9.1 > > > > > I'm also not clear are we talking about git tags here or github > > > labels? We are using git tags but that is when we cut the release on > > > the release branch. > > > > I don't know why I assumed Github labels and not git tags. I was > > obviously talking about Github labels. I'm not sure how David sees > > the use of git tags in this context. > > > > For backporting PRs, I don't mind either solutions, but I also prefer > > periodically adding the PRs with the backport prefix and the PR > > number. I guess others had some concerns with this, maybe they can > > help us understand. > > > > > > On Tue, Jun 9, 2020 at 4:06 AM Brennan Ashton > > wrote: > > > > > > On Mon, Jun 8, 2020 at 6:21 AM Abdelatif Guettouche > > > wrote: > > > > > > > > > Would tags do the same thing? > > > > > How does this work over time? > > > > > Many PRs or keep force pushing to the PR > > > > > > > > For each release there will be only one PR that hosts all the > > > > backported commits. > > > > And yes, tags would work I guess, it's easy to filter PRs with tags on > > > > Github. > > > > > > > > > How about use cherry-pick -e and add the prefix [BACKPORT] on the back > > > > > ported commits. > > > > > > > > We did something similar for PRs in the last release. Is the purpose > > > > to be able to filter out the backported commits later? > > > > > > I liked what we did last release with periodically adding a PR with > > > the backported commits. If we just keep one giant PR with the > > > backports this will make it harder for people to test the branch. > > > For the most part we had the backported PR numbers in the PR title > > > which made it really easy to match up later to figure out what did not > > > apply to the next release. I don't really have an opinion on the > > > matter of if we edit the commit, but I am not sure what the added > > > value would be. > > > > > > I'm also not clear are we talking about git tags here or github > > > labels? We are using git tags but that is when we cut the release on > > > the release branch. > > > > > > --Brennan
Re: NuttX config browser
Very nice Maciej! Good job! Kudos! On 6/15/20, Maciej Wójcik wrote: > Update on development of NuttX kconfig browser. > > It is now possible to upload and display existing `.config` file. > > [image: Screenshot from 2020-06-15 12-21-08.png] > > > What I am planning next is to provide more detail on each entry. Similar to > what Zephyr does in it's Kconfig cross-reference > https://docs.zephyrproject.org/latest/reference/kconfig/index-drivers.html > > We have the same type of information because I am using the same library. > > Any suggestions how it could look are welcome. > > Full list of changes: > https://gitlab.com/w8jcik/nuttx-config-tree-ui/-/releases/0.3 > > Am Mi., 3. Juni 2020 um 16:21 Uhr schrieb Maciej Wójcik : > >> A suggestion: when the user click on the option it should be nice to see >>> the Help for that option. >> >> >> I have added a side panel with entry description >> http://nuttx-config.nxtlabs.pl >> >> [image: Screenshot from 2020-06-03 16-08-40.png] >> >> It would be great to also show dependencies, reverse-dependencies and >> allow navigation. >> >> Could you have an option to upload a defconfig to see the settings based >>> on it? >> >> >> I should be able to do this. I could allow dropping of a file into the >> browser and then it would filter the tree based on it. Also display >> values >> next to every entry. >> >> Is it what you have in mind? If not, could you describe how it should >> work? >> >> Am Mo., 1. Juni 2020 um 15:59 Uhr schrieb David Sidrane < >> david.sidr...@nscdg.com>: >> >>> Hi Maciej, >>> >>> Could you have an option to upload a defconfig to see the settings based >>> on >>> it? >>> >>> David >>> >>> -Original Message- >>> From: Maciej Wójcik [mailto:w8j...@gmail.com] >>> Sent: Sunday, May 31, 2020 8:23 PM >>> To: dev@nuttx.apache.org >>> Subject: Re: NuttX config browser >>> >>> Hello Alan, >>> >>> A suggestion: when the user click on the option it should be nice to >>> > see the Help for that option. >>> >>> >>> Sure, I will add a side pane. >>> >>> Regarding online IDE. I was trying few times to switch to online >>> development. The problem is that to debug or even to connect to nsh, one >>> still needs local software and local copy of entire project. Which is >>> against the basic reason why we would like to develop online. It is also >>> a >>> bit difficult to come up with own, custom online IDE. It is simply a lot >>> of >>> work, for a team of people. >>> >>> That being said I can easily imagine using existing online IDE to >>> develop >>> NuttX project. It could be just described how to do it efficiently. For >>> example git repository can be cloned to GitLab and opened with their >>> IDE. >>> Then binary comes from pipeline which can be flashed to the >>> microcontroller. Some simple client can be created which automates >>> flashing. Still the issue of debugging remains. >>> >>> I will take a look at MBED and see how did they solve the issue. >>> >>> Am So., 31. Mai 2020 um 22:09 Uhr schrieb Alan Carvalho de Assis < >>> acas...@gmail.com>: >>> >>> > Hi Maciej, >>> > >>> > A suggestion: when the user click on the option it should be nice to >>> > see the Help for that option. >>> > >>> > Do you think it could be possible to do it? >>> > >>> > Did you test MBED platform in the browser ever? They have an online >>> > IDE where people can create an application, compile it and load the >>> > firmware in the board. >>> > >>> > It should be nice if we could have a way to compile NuttX in the >>> > browser, like MBED is doing for a long time (more than 8 years at >>> > least). >>> > >>> > BR, >>> > >>> > Alan >>> > >>> > On 5/31/20, Maciej Wójcik wrote: >>> > >> >>> > >> Maciej's tool is much easier to use. Maciej has several other cool >>> > >> NuttX >>> > >> tools. >>> > > >>> > > >>> > > Thank you Greg for a good word. I will work on this configuration >>> > > browser >>> > > more and I am glad to contribute it if the community will find it >>> > > useful. >>> > > Regarding the other tools, I had one more project but I >>> overcomplicated >>> > it >>> > > and it ended up nowhere. I am still working on it from time to time, >>> but >>> > I >>> > > can't promise it will ever be production ready. >>> > > >>> > > Am So., 31. Mai 2020 um 19:18 Uhr schrieb spudaneco < >>> spudan...@gmail.com >>> > >: >>> > > >>> > >> The configuration document he is referring to is not in the >>> repository. >>> > >> I >>> > >> used to create it only for releases using a custom tool at >>> > >> tools/mkconfigvars.shMaciej's tool is much easier to use.Maciej has >>> > >> several >>> > >> other cool NuttX tools. In a meritocracy, I think contributing >>> > >> these >>> > >> to >>> > >> the project would score pretty high (hint, hint, hint)Sent from >>> Samsung >>> > >> tablet. >>> > >> Original message From: Brennan Ashton < >>> > >> bash...@brennanashton.com> Date: 5/31/20 11:04 AM (GMT-06:00) To: >>> > >> dev@nuttx.apache.org Subject: Re: NuttX con
Re: NXView
Hi Alan, Thanks for sharing this. Indeed, I haven't been aware of such a tool. I'll try it out. BR, Erdem Alan Carvalho de Assis , 14 Haz 2020 Paz, 21:56 tarihinde şunu yazdı: > Hi Erdem, > > Right, I understood your idea! > > In fact Maciej already created it, see: > > https://hackaday.io/project/94372-upm-nuttx-project-manager > > https://gitlab.com/w8jcik/upm > > Did you try it? > > BR, > > Alan > > On 6/14/20, Erdem MEYDANLI wrote: > > Hi Alan, > > > > > > You are right. NuttX has a more comprehensive scope. For sure, what I > > proposed requires a lot of work. > > > > > > With or without OpenOCD, what I meant by SDK was a combination of > (actively > > maintained) buildroot and a meta-tool like *West *in Zephyr. > > > > > > Those who haven't heard of Zephyr's meta-tool might want to look at this: > > https://docs.zephyrproject.org/latest/guides/west/build-flash-debug.html > > > > > > I assume that the 'SDK' solves all dependency issues, and the meta-tool > > offers the functionality below: > > > > > > nxtool flash > > > > nxtool debug > > > > nxtool monitor (imagine this initiates @Greg's idea as part of its > > functionality.) > > > > > > People who are already familiar with RTOSes and MCU development > undoubtedly > > follow the current installation steps quickly. Maybe they already > > established a mini-automation for their development process. However, > when > > it comes to beginners, the installation can still be a pain in the neck. > > > > > > So, this discussion is about the unborn NXView, and I don't want to > ramble > > on about it. I find the NXView idea very beneficial. And referring to > > Greg's paragraph below, having a meta-tool that I try to explain above > > might add significant value as well. > > > >>> > > I believe that such a tool would be a valuable addition to the NuttX > > ecology. I think that such a tool would move NuttX from a basic, > > primitive open source OS project and into full competition with > > commercial products (in terms of features and usage... we are not > > actually in competition with anyone). > > << > > > > > > Alan Carvalho de Assis , 14 Haz 2020 Paz, 18:51 > > tarihinde şunu yazdı: > > > >> Hi Erdem, > >> > >> On 6/14/20, Erdem MEYDANLI wrote: > >> sic > >> > > >> > I do agree. That would be such an invaluable tool. BTW, speaking of > >> > particular hardware like FT245 gives me an idea. Well, this might > sound > >> > a > >> > little bit irrelevant, but what about taking it a step further and > >> > developing a mini-SDK (NX-SDK) as the one Zephyr has? Still not as a > >> > very > >> > active contributor, but an enthusiastic follower of the NuttX project, > >> > I > >> > think that the entry barrier of the project is still not that low. > >> > Onboarding takes some time. Having a custom SDK that includes not only > >> > a > >> > tracer, but also other helper tools (e.g., flasher/debugger for the > >> > supported boards) would facilitate the adaptation process of the > >> newcomers. > >> > Finally, rather than relying on some particular ICs, would it be more > >> > practical to build such a tool by creating a (custom) fork of OpenOCD? > >> > > >> > >> In the past NuttX used to have a Buildroot that was able to generate > >> the toolchain, etc. It is still around, some time ago David Alessio > >> fixed it. > >> > >> At first place the SDK idea appears good, but there are many issues. > >> > >> We have many architectures, we support MCU/CPU from 8 to 64-bit > >> (Zephyr and others are 32-bit only and mainly ARM, RISC-V and Xtensa). > >> I could go on citing other issues... > >> > >> Currently at least on Linux (Debian, Ubuntu, ...) and Ubuntu Shell on > >> Windows it is very easy, just some apt/apt-get away. Even the > >> kfrontend is already there, you don't need to compile it anymore. I > >> think the main issue is that OpenOCD version is too old. But creating > >> a fork of OpenOCD is not a good idea. > >> > >> OpenOCD is a project that deserves more attention, it is like the SSH, > >> many people/companies uses it and people only not it was a "backbone" > >> when it broke. > >> The last OpenOCD release was 3 years ago and I don't see any move to a > >> new release. If they release a new version now, maybe it will delay > >> about 2 years to get it officially on Linux distros. > >> > >> I heard that OpenOCD was going to be part of Linux Foundation, but > >> nothing happened yet. Let see! > >> > >> BR, > >> > >> Alan > >> > > >
