NuttX download page
HI, Re [1] I note it’s calling the downloads "Apache NuttX”, AFAIK there are not Apache downloads. That page can link pre Apache downloads but it need to be made very clear that they are not Apache releases. We‘ve had this conversation before right? I also note that page is also is linking to the mirrors but the it doesn’t seem that that the downloads are there - that’s a good thing. I can see 8.2 downloads here [2] Thanks, Justin 1. http://nuttx.apache.org/download/ 2. https://bitbucket.org/nuttx/nuttx/downloads/
Re: Bug Tracking
github project boards can span multiple repos https://help.github.com/en/github/managing-your-work-on-github/about-project-boards On Wed, Jan 15, 2020 at 12:09 AM Gregory Nutt wrote: > > > The Mynewt project, for example, has many repositories. I can > > find the page but I recall that it is on the order of a dozen or so > > repositories. ... > > 17 > > See https://gitbox.apache.org/repos/asf > >
Re: NuttX download page
Yep, it's on my to-do after you clarified what we can do for the non Apache releases to go and fix the releases page up. Something like this is what I was thinking: https://daffodil.apache.org/releases/ --Brennan On Wed, Jan 15, 2020, 12:59 AM Justin Mclean wrote: > HI, > > Re [1] I note it’s calling the downloads "Apache NuttX”, AFAIK there are > not Apache downloads. That page can link pre Apache downloads but it need > to be made very clear that they are not Apache releases. We‘ve had this > conversation before right? > > I also note that page is also is linking to the mirrors but the it doesn’t > seem that that the downloads are there - that’s a good thing. I can see 8.2 > downloads here [2] > > Thanks, > Justin > > 1. http://nuttx.apache.org/download/ > 2. https://bitbucket.org/nuttx/nuttx/downloads/
RE: [DISCUSS]Bug Tracking
+1 for Github issues per repo. Repos can be cross referenced in markup. Assignees can be assigned labels can be assigned. Projects (roll up across repos) can be assigned. Milestones can be assigned. UI is simple and effective Query by any of the above attributes. The interfaces is present when on Github - there is no need secondary login/account The content can be rich. We can add issue from email if someone does not have access to github. -1 for any other external issue tracking system. They add no value above what is built into ghithub. They complicate coordination (PR closes issue). In a general sense: The choice if an external system violates 3NF. I do not agree that issues OR Code changes will continue to come in by email. I believe the root cause of that historical dataflow is an artifact bad process and tooling. When the correct process are in place, as is the correct tooling, there can be support for historical manual ways, but it will be less used because it is not as efficient, it is not fool proof or effective. David -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Tuesday, January 14, 2020 5:29 PM To: dev@nuttx.apache.org Subject: Re: [DISCUSS]Bug Tracking I presume that there will be vote coming in the next few days for the Bug Tracking solution. This thread, then, is really the [DISCUSS] thread prior to the vote, right? I have no idea what the voting options will be, but we should probably label this as [DISCUSS] so people will appreciate that it is important for their opinions to be heard.
Re: [DISCUSS]Bug Tracking
On Wed, Jan 15, 2020, 10:09 AM David Sidrane wrote: > +1 for Github issues per repo. > > Repos can be cross referenced in markup. > Assignees can be assigned > labels can be assigned. > Projects (roll up across repos) can be assigned. > Milestones can be assigned. > UI is simple and effective Query by any of the above attributes. > The interfaces is present when on Github - there is no need secondary > login/account > The content can be rich. > Where does the GitHub Projects reside? What I was pushing for was a single place not per repo. To me the core OS one was the right place, but that seems to be off the table, I fail to see how tracking a release including the apps (especially if the tickets are open against the apps project) is tainting the quality of the OS. --Brennan >
RE: [DISCUSS]Bug Tracking
> Where does the GitHub Projects reside? Per repo and per Organization > To me the core OS one was the right place, but that seems to be off the table, I fail to see how tracking a release including the apps (especially if the tickets are open against the apps project) is tainting the quality of the OS. I think there is a perception that "How good" the OS is should not be judged by "How good" the apps are. So 10 Issues all on Apps and 1 issue against the OS but all logged in the OS repo is what is meeting resistance. Call it "quality inferences" Myself, I do not share that point of view. In my view: an App or OS bug is still a problem if we are using both OS and APPs. I think about where issues belong more as a matter of compartmentalization and not quality inferences: Having apps that has issues focuses the conversation on APPS. Having OS that has issues focuses the conversation on the OS. If a user does not use apps then why tell them of all the issues in the OS repo? If there is linkage use Markup to link them [Effects APP](url) and [Effects OS](url) and that is all that is needed to cross reference them. David -Original Message- From: Brennan Ashton [mailto:bash...@brennanashton.com] Sent: Wednesday, January 15, 2020 10:24 AM To: dev@nuttx.apache.org Subject: Re: [DISCUSS]Bug Tracking On Wed, Jan 15, 2020, 10:09 AM David Sidrane wrote: > +1 for Github issues per repo. > > Repos can be cross referenced in markup. > Assignees can be assigned > labels can be assigned. > Projects (roll up across repos) can be assigned. > Milestones can be assigned. > UI is simple and effective Query by any of the above attributes. > The interfaces is present when on Github - there is no need secondary > login/account > The content can be rich. > Where does the GitHub Projects reside? What I was pushing for was a single place not per repo. To me the core OS one was the right place, but that seems to be off the table, I fail to see how tracking a release including the apps (especially if the tickets are open against the apps project) is tainting the quality of the OS. --Brennan >
Re: [DISCUSS]Bug Tracking
Where does the GitHub Projects reside? What I was pushing for was a single place not per repo. To me the core OS one was the right place, but that seems to be off the table, I fail to see how tracking a release including the apps (especially if the tickets are open against the apps project) is tainting the quality of the OS. That option is certainly off the table for me. That is the only option that would force me to vote -1. I will support every other option suggested.
Can't make work shared file for CAN
Hi! When I use usual file descriptor for can device: file_open(&CANmodule->file, "/dev/can0", O_RDWR); everything works, thread blocks if further read() and, when can message receive, returns correct nbytes. When I open can0 with file_open(&file, "/dev/can0", O_RDWR); it opens correctly and file_ioctl seems to work. But file_read from &file do not block and return immediately same nbytes as requested with some garbage in data. But there is no data on CAN bus. Polling (of course with POLLFILE mask) also do not get blocked and return POLLIN event immediately. Doing file_detach() as describe in https://www.nuttx.org/doku.php?id=wiki:nxinternal:detachedfds leads to the same result. Any thoughts? Thanks. -- With regards, Oleg Evseev
Re: Can't make work shared file for CAN
Oleg: do you use an extended ID or standard ID? And do you use the CAN app from examples? Verstuurd vanaf mijn iPhone > Op 15 jan. 2020 om 22:02 heeft Oleg Evseev het volgende > geschreven: > > Hi! > > When I use usual file descriptor for can device: > file_open(&CANmodule->file, "/dev/can0", O_RDWR); > everything works, thread blocks if further read() and, when can message > receive, returns correct nbytes. > > When I open can0 with > file_open(&file, "/dev/can0", O_RDWR); > > it opens correctly and file_ioctl seems to work. But file_read from &file > do not block and return immediately same nbytes as requested with some > garbage in data. But there is no data on CAN bus. Polling (of course with > POLLFILE mask) also do not get blocked and return POLLIN event immediately. > > Doing file_detach() as describe in > https://www.nuttx.org/doku.php?id=wiki:nxinternal:detachedfds leads to the > same result. > > Any thoughts? > > Thanks. > > -- > With regards, > Oleg Evseev
Re: Can't make work shared file for CAN
Hi! Is it really matters? I think the issue is more about file descriptors, file pointers and so on. CAN is configured with extended ID. Yes, I did use CAN app from examples, it works. Implementation in my own app also works fine if I use file descriptor when opened /dev/can0. In different threads of one task group - no problems. Now I want to also send messages from another thread from different task group, but file descriptors cannot be used by different tasks. So I'm trying to use internal OS interface from https://www.nuttx.org/doku.php?id=wiki:nxinternal:detachedfds But file_read on file pointer doesn't work in the same way as read on file descriptor, even if it is in the same thread - right after file_open! чт, 16 янв. 2020 г. в 00:11, Disruptive Solutions < disruptivesolution...@gmail.com>: > Oleg: do you use an extended ID or standard ID? And do you use the CAN app > from examples? > > Verstuurd vanaf mijn iPhone > > > Op 15 jan. 2020 om 22:02 heeft Oleg Evseev het > volgende geschreven: > > > > Hi! > > > > When I use usual file descriptor for can device: > > file_open(&CANmodule->file, "/dev/can0", O_RDWR); > > everything works, thread blocks if further read() and, when can message > > receive, returns correct nbytes. > > > > When I open can0 with > > file_open(&file, "/dev/can0", O_RDWR); > > > > it opens correctly and file_ioctl seems to work. But file_read from &file > > do not block and return immediately same nbytes as requested with some > > garbage in data. But there is no data on CAN bus. Polling (of course with > > POLLFILE mask) also do not get blocked and return POLLIN event > immediately. > > > > Doing file_detach() as describe in > > https://www.nuttx.org/doku.php?id=wiki:nxinternal:detachedfds leads to > the > > same result. > > > > Any thoughts? > > > > Thanks. > > > > -- > > With regards, > > Oleg Evseev >
Re: Can't make work shared file for CAN
But file_read on file pointer doesn't work in the same way as read on file descriptor, even if it is in the same thread - right after file_open! That would be surprising because read() just calls file_read(). I would expect the behaviors to be the same. If there is a semaphore locking issue, I would first be suspicious of drivers/can/can.c. Did you try enabling CAN debug. Perhaps, if you are lucky, it will show something of interest.
Re: Towards making your first Apache release
Hi, Is anyone willing to be the first release manager? Thanks, Justin
Re: Towards making your first Apache release
Hello Justin, I cannot determine what the capabilities are that are needed and what the impact in hours will be? And I would need guidance I have a strong passion about Nuttx, but maybe thats not enough... Ben Verstuurd vanaf mijn iPhone > Op 15 jan. 2020 om 23:52 heeft Justin Mclean het > volgende geschreven: > > Hi, > > Is anyone willing to be the first release manager? > > Thanks, > Justin
Re: Towards making your first Apache release
Is anyone willing to be the first release manager? My understanding is that the release manager does not necessarily do the release, but is the point of contact and coordinator for releases and needs to sign releases. Is that true? So the job should not sound as scary as the title implies. At one point in the past, Duo Zhang mentioned a set of tools this his project used to automatically generate ReleaseNotes and other parts of the release. If Duo is still listening in, can you refresh that memory? Greg
Re: Towards making your first Apache release
I have been reading: http://www.apache.org/dev/release-publishing.html Verstuurd vanaf mijn iPhone > Op 15 jan. 2020 om 23:52 heeft Justin Mclean het > volgende geschreven: > > Hi, > > Is anyone willing to be the first release manager? > > Thanks, > Justin
Re: Towards making your first Apache release
Hi, > My understanding is that the release manager does not necessarily do the > release, but is the point of contact and coordinator for releases and needs > to sign releases. Is that true? Yep that correct it more a co-ordination role to make sure everything gets done. The release manager will typically get the release notes together, make the release candidates and they start and finish the vote for them, but others can also do those tasks, it really up to the project on how they want to do this. On some projects that’s not much work on others it’s a lot of work. For your first there going to be some decisions that the PPMC will need to make and some of those may impact how much work it’s going to be. While anyone can be a release manager, it’s a little easier if you are a PPMC member or committer as you need access to stage the release candidates for instance. [1] is ASF policy, but remember you don’t need to get everything right on your first try especially if you use the work in progress disclaimer. [2] There are also some extra requirements for an incubating release [3] - It must have incubating in the artefact name. - It must have a disclaimer. - RC’s need to be placed in http://www.apache.org/dev/incubator/nuttx - Voting occurs on the dev list first, then on the incubator general list. - Releases are at http://www.apache.org/dist/incubator/nuttx Thanks, Justin. 1. http://www.apache.org/dev/release-publishing.html 2. https://incubator.apache.org/policy/incubation.html#work_in_progress_disclaimer 3. https://incubator.apache.org/policy/incubation.html#releases
Re: Towards making your first Apache release
HI, > I cannot determine what the capabilities are that are needed and what the > impact in hours will be? Hard to estimate hours but it should be more than a few hours week, the first release generally take some time to get together 2 to 4 weeks is typically, but some projects do it quicker and some take months. > And I would need guidance I have a strong passion about Nuttx, but maybe > thats not enough… Mentors are here to help. I created and reviewed 100’s of release (about 500 I think) so know the process and what issues you may run into. This little presentation (I've given a few times) help as well, [1] Thanks, Justin 1. https://github.com/apache/incubator-training/tree/master/content/ApacheWay/IncubatorReleases 2. https://github.com/apache/incubator-training/blob/master/content/ApacheWay/IncubatorReleases/src/main/asciidoc/index.adoc
Podling Nuttx Report Reminder - February 2020
Dear podling, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Wed, 19 February 2020, 10:30 am PDT. The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted 2 weeks before the board meeting, to allow sufficient time for review and submission (Wed, February 05). Please submit your report with sufficient time to allow the Incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is 2 weeks prior to the board meeting. Candidate names should not be made public before people are actually elected, so please do not include the names of potential committers or PPMC members in your report. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. * How does the podling rate their own maturity. This should be appended to the Incubator Wiki page at: https://cwiki.apache.org/confluence/display/INCUBATOR/February2020 Note: This is manually populated. You may need to wait a little before this page is created from a template. Note: The format of the report has changed to use markdown. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC
Re: Towards making your first Apache release
I'm also willing to take this on or help someone else for the first release. Can't rush the code, but it would be nice to get the other bits in place for a release. --Brennan On Wed, Jan 15, 2020, 3:37 PM Justin Mclean wrote: > HI, > > > I cannot determine what the capabilities are that are needed and what > the impact in hours will be? > > Hard to estimate hours but it should be more than a few hours week, the > first release generally take some time to get together 2 to 4 weeks is > typically, but some projects do it quicker and some take months. > > > > And I would need guidance I have a strong passion about Nuttx, but > maybe thats not enough… > > Mentors are here to help. I created and reviewed 100’s of release (about > 500 I think) so know the process and what issues you may run into. > > This little presentation (I've given a few times) help as well, [1] > > Thanks, > Justin > > 1. > https://github.com/apache/incubator-training/tree/master/content/ApacheWay/IncubatorReleases > 2. > https://github.com/apache/incubator-training/blob/master/content/ApacheWay/IncubatorReleases/src/main/asciidoc/index.adoc > > >
[DISCUSS] Remove Windows Native support?
I would like to open a discussion for 72 hours then call a vote. The topic is "Should we remove Windows native build support?" What is the Windows native build? Is is a build option that supports building NuttX in a pure Windows environment such as from a Windows IDE or from CMD/PowerShell command line. It differs primarily in that it cannot use Bash features or Bash .sh scripts, but instead must use commands from CMD.exe and .bat scripts. Please see the discussion here that is leading to the vote: https://github.com/apache/incubator-nuttx/pull/102 I think this needs a vote because (1) it is clear contradiction to the Inviolables and (2) it could have significant, negative impact to NuttX users down the road (although I don't think any current NuttX user would be impacted). The cost vs the benefit is not entirely clear to me. PRO Removal: * The Windows native native support is seldom used and lags the POSIX environment builds. As a consequence, it is usually broken. Historically, people who need the native have to contribute fixes to get the build back into working shape. * Documentation current claims that NuttX supports the Windows native build but that build is never verified and is probably not working at any given time. * The Windows native build adds a lot complexity to the build system. ANTI Removal * Although, the Windows native build is probably broken at any given time, it has historically not been a huge effort to get it back into shape. That might be different now since there has been a significant re-write to the apps/ build, in particular. * There are users whose customer base absolutely requires the Windows native build. Good user oriented support would require that we support the Windows the native build. * Removing the Windows native build for reasons of convenience and expediency and without regard to the needs of the NuttX user is very much in contradiction to the OS principles (i.e., the Inviolables). Please offer your opinion. You should not take the position of someone who only cares about your personal use of Linux. Please think in terms of the bigger picture of what is good for the project and for the users of the project in the long run. I will end the discussion and start the vote in the evening of January 18. Greg
Re: [DISCUSS] Remove Windows Native support?
I would like to open a discussion for 72 hours then call a vote. The topic is "Should we remove Windows native build support?" There have been several SDKs build for Windows native in the past. One obstacle for the Windows native build is that it requires a Windows native port of kconfig-frontends. That has actually been done a couple of times to support NuttX user SDKs: * http://uvc.de/posts/linux-kernel-configuration-tool-mconf-under-windows.html * http://reclonelabs.com/more-kconfig-awesomeness-for-windows/ These work quite nicely. The reclonelabs is the most up-to-date and the most frequently used. Although the UVC Ingeniere gets credit for being the first. (I know, there is a Python version too). The relevance of this these to the current discussion topic is that this shows the extent to which motivated NuttX users will go to get the pure Windows native build. For this small set of users, if NuttX did not build natively on Windows, they would not use it. So please consider the issues and the PROs and CONs. Don't base the discussion on what I like to use and how people do things in the little world I live in. We need to think broadly about the value of Windows native support before we kiss off potential users. Greg
Re: [DISCUSS] Remove Windows Native support?
I would like to open a discussion for 72 hours then call a vote. The topic is "Should we remove Windows native build support?" It occurs to me that there are really three options: 1. Remove all support for Windows native builds 2. Keep the seldom unverified Window native build, just as we do now. If we do this, we should add Disclaimers that Windows native is a DIY project and probably does not work out-of-the-box. 3. Provide ongoing support and verification of the Windows native build. This would take some initial effort to get up and running, but then should be verifiable through automated tools.
Re: [DISCUSS] Remove Windows Native support?
I would like to open a discussion for 72 hours then call a vote. The topic is "Should we remove Windows native build support?" It occurs to me that there are really three options: 1. Remove all support for Windows native builds 2. Keep the seldom unverified Window native build, just as we do now. If we do this, we should add Disclaimers that Windows native is a DIY project and probably does not work out-of-the-box. 3. Provide ongoing support and verification of the Windows native build. This would take some initial effort to get up and running, but then should be verifiable through automated tools. And perhaps a fourth. I have never tried this, but I think it might be possible to start a standard MSYS2 build from a CMD/PowerShell window. I think it would just be a matter of setting up the PATH correctly and starting the build with the MSYS2 make. It might also require supporting Windows style paths. If that were possible, perhaps it could meet all needs.
Re: [DISCUSS] Remove Windows Native support?
Hi, The linux bash shell works on windows 10 (via WSL) these days. Is that an option? Justin
Re: [DISCUSS] Remove Windows Native support?
Item 2 isn't a good option: a broken build system just give the user a very bad impression that OS self isn't workable or stable. It's better that we fully support Windows native or remove from the list at all. What I means the full is that all config must pass the automation build and run the build system regularly like other host. On Thu, Jan 16, 2020 at 12:59 PM Justin Mclean wrote: > > Hi, > > The linux bash shell works on windows 10 (via WSL) these days. Is that an > option? > > Justin
