Re: Roadmap?
On Wed, Aug 12, 2020 at 12:07 PM Gregory Nutt wrote: > > How/who would prioritize and > schedule implementation of roadmap items? How could accomplish any of > this with only a volunteer organization and no project management with > any authority? Open source tends to be driven by people scratching their own itches, so I think we should try to flow with that rather than against it. The roadmap will likely begin as a jumble of everyone's wishlist items, and things would gradually get prioritized based on how popular and urgent the items are to those who do the work. But who will do the work? In the spirit of open source, whoever needs/wants it to get done, whether they're already committers or people new to the project, whether volunteer or paid. Importantly, if something gets implemented ahead of schedule (because it's urgent to someone), that's okay. Things shouldn't be delayed because the roadmap says so. The roadmap should be a guideline, not a hard rule. Unless there are technical prerequisites where one feature must be implemented before another becomes possible. Regarding "no project management with any authority," although the PMC doesn't have authority to order people to work on certain things at a certain time, the way a company's management does, it does have authority, through discussions and voting, to decide what kinds of changes fit the project's needs. So if, for example, someone wants to merge a change that cranks up our memory usage to the stratosphere, we can say sorry, it's not a good fit. And the road map, in conjunction with the INVIOLABLES, can be a good way to articulate what is likely a good fit and what isn't. Just my 2¢ Nathan
Re: Roadmap?
Thanks for catching that Abdelatif. I moved the NuttX project board here: https://github.com/apache/incubator-nuttx/projects/2 We can delete it if we don't like it. -adam On Wed, Aug 12, 2020 at 11:43 AM Adam Feuer wrote: > On Wed, Aug 12, 2020 at 11:40 AM Abdelatif Guettouche < > abdelatif.guettou...@gmail.com> wrote: > >> Was it intentional to create it in Apache's and not here: >> https://github.com/apache/incubator-nuttx/projects? > > > Oops. No. :) I'll move it or recreate it there. > > -adam > -- Adam Feuer
Re: Roadmap?
We probably should also include all Github Issues that are listed as enhancements. If we use a Github Project Board like Brennan suggested this would be pretty easy to link them there. Jira will link to github issues as well, as I recall. We went through all of this in the early days of the project to select an Issue tracking system but opted for github Issues which are inadequate for the purpose at hand. Brennan looked into Jira at that time but, I think, was under-impressed. I should let Brennan speak for himself. The only real advantage of Jira is that it is a full-featured, professional (and expensive) project management system that Apache licenses and makes available for out use.
Re: Roadmap?
On Wed, Aug 12, 2020 at 11:40 AM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > Was it intentional to create it in Apache's and not here: > https://github.com/apache/incubator-nuttx/projects? Oops. No. :) I'll move it or recreate it there. -adam
Re: Roadmap?
> Well I just made a board for us: Was it intentional to create it in Apache's and not here: https://github.com/apache/incubator-nuttx/projects? On Wed, Aug 12, 2020 at 7:39 PM Gregory Nutt wrote: > > Jira is another option available to us. > >
Re: Roadmap?
Jira is another option available to us.
Re: Roadmap?
Well I just made a board for us: https://github.com/orgs/apache/projects/13 If we don't like it we can delete it. I added the items from the wiki list as cards in Future, we should really convert them to issues and add more description to them. We can add the issues that we're working on to the current quarter if we want. I don't know what the columns should be so I just added quarters (Q3 2020, Q4 2020, etc.) like Github has. If anyone has a better idea for this let me know. I changed the wiki page to point to this. -adam On Wed, Aug 12, 2020 at 11:25 AM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > > Seems doable. Does anyone have any objections to me creating a board like > this for NuttX? > > Not from me, I think with Github's projects (or milestones) and > consistent labeling of issues and PRs people would have a better > overview. > Anyone can then follow the development of the feature of interest. > > On Wed, Aug 12, 2020 at 7:04 PM Gregory Nutt wrote: > > > > > > > I made a wiki page with the raw list of things that people are asking > for > > > in this thread: > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/Roadmap > > > > > > Check it out, add anything I missed, and correct errors I made. > > > > > > Maybe the next step would be to try to complete this list, then maybe > > > prioritize it, connecting it with releases and the things people have > > > energy working on and collaborating together on? > > > > > > If what you want to put here doesn't fit on the page, make a child > page. :) > > We probably should also include all Github Issues that are listed as > > enhancements. > -- Adam Feuer
Re: Roadmap?
> Seems doable. Does anyone have any objections to me creating a board like this for NuttX? Not from me, I think with Github's projects (or milestones) and consistent labeling of issues and PRs people would have a better overview. Anyone can then follow the development of the feature of interest. On Wed, Aug 12, 2020 at 7:04 PM Gregory Nutt wrote: > > > > I made a wiki page with the raw list of things that people are asking for > > in this thread: > > > > https://cwiki.apache.org/confluence/display/NUTTX/Roadmap > > > > Check it out, add anything I missed, and correct errors I made. > > > > Maybe the next step would be to try to complete this list, then maybe > > prioritize it, connecting it with releases and the things people have > > energy working on and collaborating together on? > > > > If what you want to put here doesn't fit on the page, make a child page. :) > We probably should also include all Github Issues that are listed as > enhancements.
Re: Roadmap?
On Wed, Aug 12, 2020 at 11:04 AM Gregory Nutt wrote: > We probably should also include all Github Issues that are listed as > enhancements. > If we use a Github Project Board like Brennan suggested this would be pretty easy to link them there. -adam -- Adam Feuer
Re: Roadmap?
These are projects which gives you a different view from issues. But there's also a "milestone": https://docs.github.com/en/github/managing-your-work-on-github/creating-and-editing-milestones-for-issues-and-pull-requests https://docs.github.com/en/github/managing-your-work-on-github/associating-milestones-with-issues-and-pull-requests https://docs.github.com/en/github/managing-your-work-on-github/viewing-your-milestones-progress You can see in the last link how it is used for handling versions: On Wed, Aug 12, 2020, at 15:02, Adam Feuer wrote: > Brennan, > > Re: needing an Apache CWiki account, ok, I get it. So something like this? > > Github's public roadmap: > https://github.com/github/roadmap/projects/1 > > Seems doable. Does anyone have any objections to me creating a board like > this for NuttX? > > -adam > > On Wed, Aug 12, 2020 at 10:54 AM Brennan Ashton > wrote: > > > On Wed, Aug 12, 2020, 10:40 AM Adam Feuer wrote: > > > > > Folks, > > > > > > I made a wiki page with the raw list of things that people are asking for > > > in this thread: > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/Roadmap > > > > > > I am thinking this might be easier to manage as GH tickets with a label, > > and then link on a project board if we want an overview. The thing I really > > don't like about the wiki is you need an Apache account to add things which > > creates an unfortunate barrier to it and it is even harder to then link to > > PRs and code. > > > > In a couple other projects we had a process where people could bring > > forward something like a NuttX Feature Proposal (NFP) where it would be > > outlined and the details sorted possibly some PoC done if it was large and > > then it could be accepted and executed on. This is a slow process that is > > not a bad thing for major changes that have a lot of implications. > > > > > -- > Adam Feuer >
Re: Roadmap?
I made a wiki page with the raw list of things that people are asking for in this thread: https://cwiki.apache.org/confluence/display/NUTTX/Roadmap Check it out, add anything I missed, and correct errors I made. Maybe the next step would be to try to complete this list, then maybe prioritize it, connecting it with releases and the things people have energy working on and collaborating together on? If what you want to put here doesn't fit on the page, make a child page. :) We probably should also include all Github Issues that are listed as enhancements.
Re: Roadmap?
Brennan, Re: needing an Apache CWiki account, ok, I get it. So something like this? Github's public roadmap: https://github.com/github/roadmap/projects/1 Seems doable. Does anyone have any objections to me creating a board like this for NuttX? -adam On Wed, Aug 12, 2020 at 10:54 AM Brennan Ashton wrote: > On Wed, Aug 12, 2020, 10:40 AM Adam Feuer wrote: > > > Folks, > > > > I made a wiki page with the raw list of things that people are asking for > > in this thread: > > > > https://cwiki.apache.org/confluence/display/NUTTX/Roadmap > > > I am thinking this might be easier to manage as GH tickets with a label, > and then link on a project board if we want an overview. The thing I really > don't like about the wiki is you need an Apache account to add things which > creates an unfortunate barrier to it and it is even harder to then link to > PRs and code. > > In a couple other projects we had a process where people could bring > forward something like a NuttX Feature Proposal (NFP) where it would be > outlined and the details sorted possibly some PoC done if it was large and > then it could be accepted and executed on. This is a slow process that is > not a bad thing for major changes that have a lot of implications. > -- Adam Feuer
RE: Roadmap?
+1 (I know it is not a vote, I am just agreeing) -Original Message- From: Brennan Ashton [mailto:bash...@brennanashton.com] Sent: Wednesday, August 12, 2020 10:54 AM To: dev@nuttx.apache.org Subject: Re: Roadmap? On Wed, Aug 12, 2020, 10:40 AM Adam Feuer wrote: > Folks, > > I made a wiki page with the raw list of things that people are asking for > in this thread: > > https://cwiki.apache.org/confluence/display/NUTTX/Roadmap I am thinking this might be easier to manage as GH tickets with a label, and then link on a project board if we want an overview. The thing I really don't like about the wiki is you need an Apache account to add things which creates an unfortunate barrier to it and it is even harder to then link to PRs and code. In a couple other projects we had a process where people could bring forward something like a NuttX Feature Proposal (NFP) where it would be outlined and the details sorted possibly some PoC done if it was large and then it could be accepted and executed on. This is a slow process that is not a bad thing for major changes that have a lot of implications.
Re: Roadmap?
On Wed, Aug 12, 2020, 10:40 AM Adam Feuer wrote: > Folks, > > I made a wiki page with the raw list of things that people are asking for > in this thread: > > https://cwiki.apache.org/confluence/display/NUTTX/Roadmap I am thinking this might be easier to manage as GH tickets with a label, and then link on a project board if we want an overview. The thing I really don't like about the wiki is you need an Apache account to add things which creates an unfortunate barrier to it and it is even harder to then link to PRs and code. In a couple other projects we had a process where people could bring forward something like a NuttX Feature Proposal (NFP) where it would be outlined and the details sorted possibly some PoC done if it was large and then it could be accepted and executed on. This is a slow process that is not a bad thing for major changes that have a lot of implications.
Re: Roadmap?
Folks, I made a wiki page with the raw list of things that people are asking for in this thread: https://cwiki.apache.org/confluence/display/NUTTX/Roadmap Check it out, add anything I missed, and correct errors I made. Maybe the next step would be to try to complete this list, then maybe prioritize it, connecting it with releases and the things people have energy working on and collaborating together on? If what you want to put here doesn't fit on the page, make a child page. :) cheers adam On Wed, Aug 12, 2020 at 9:52 AM Alan Carvalho de Assis wrote: > Hi Matous, > > Did you see this CANopen implementation: > > https://github.com/rscada/libcanopen > > Now it should be easy to use because NuttX supports SocketCAN. > > BR, > > Alan > > On 8/12/20, Matous Pokorny wrote: > > Hello! > > > > I definitely agree with all the words written below and I would like to > add > > few wishes. > > > > I am interested in industrial devices communicating by fieldbuses. I use > > the NuttX port of FreeModbus stack and I would like to see more port of > > communication stacks like this. I prefer CANopen and Profinet, There are > > several open source communication stack for these protocols. > > > > Thank you and have a nice day. > > _ > > *Matouš Pokorný* | Embedded system developer > > DataVision s.r.o. | Czech Republic > > > > st 5. 8. 2020 v 18:48 odesílatel Matias N. napsal: > > > >> On Wed, Aug 5, 2020, at 13:35, Maciej Wójcik wrote: > >> > 1) More opinionated documentation > >> > a) In particular clear instructions: > >> > – where to get compilers for C/C++ > >> > – how to setup project with an application outside of nuttx, and > >> clear > >> > [apps], [libs], [board], [nuttx] structure > >> > – how to set up your own board > >> > These questions are recurring. They were asked on the mailing list > >> recently > >> > again. They are basic things and they should be the second page of > >> > documentation. > >> > b) Typical policy for documentation is that when people ask, the > >> > answer > >> > should be put to documentation and the link sent back as an answer. > >> > c) Table of supported features on different platforms and boards, as > >> > discussed recently. For people who want to use NuttX to feel safe and > >> know > >> > how much they need to contribute to make their project work. > >> > >> Completely agree on the above. I would add that when people add a new > >> board they document it > >> following a set of guidelines (maybe based on a template). Also, new > >> features or breaking changes > >> should be accompanied by documentation changes. Distributing the load on > >> maintaining the documentation > >> IMHO is the way to keep it updated. > >> > >> > 2) Package management > >> > Database where people can submit whatever they want, as long as it > >> > works > >> > and they are willing to maintain it. > >> > Description on what such packages need to fulfill to work with NuttX. > >> Some > >> > simple command line tool to inject packages to NuttX projects. > >> > >> On my "NuttX workspace manager" ( > >> https://gitlab.com/nuttx_projects/nuttx_workspace_manager) I have this > >> mechanism that allows you to simply drop a directory containing an app > >> inside an "extra_apps" directory. This works > >> by having a symlink from apps/external point to this directory, where > >> NuttX looks for external apps. The trick is to > >> have a Make.defs recursively including Make.defs from subdirectories and > >> a > >> Makefile including "Directory.mk". This are the files that are placed > >> inside extra_apps/: > >> > https://gitlab.com/nuttx_projects/nuttx_workspace_manager/-/tree/master/files/extra_apps > . > >> If external/ would already have this set up, it would indeed be a matter > >> of > >> dropping an app there. > >> > >> Furthermore, I personally like to use submodules but even if you simply > >> clone or download a git repo containing just the app, you wouldn't need > a > >> central database of apps, just a git repo for each app. If some sort of > >> "central repository" is desired, a special github organization could be > >> used to collect contributed apps. > >> > >> I have
Re: Roadmap?
Hi Matous, Did you see this CANopen implementation: https://github.com/rscada/libcanopen Now it should be easy to use because NuttX supports SocketCAN. BR, Alan On 8/12/20, Matous Pokorny wrote: > Hello! > > I definitely agree with all the words written below and I would like to add > few wishes. > > I am interested in industrial devices communicating by fieldbuses. I use > the NuttX port of FreeModbus stack and I would like to see more port of > communication stacks like this. I prefer CANopen and Profinet, There are > several open source communication stack for these protocols. > > Thank you and have a nice day. > _ > *Matouš Pokorný* | Embedded system developer > DataVision s.r.o. | Czech Republic > > st 5. 8. 2020 v 18:48 odesílatel Matias N. napsal: > >> On Wed, Aug 5, 2020, at 13:35, Maciej Wójcik wrote: >> > 1) More opinionated documentation >> > a) In particular clear instructions: >> > – where to get compilers for C/C++ >> > – how to setup project with an application outside of nuttx, and >> clear >> > [apps], [libs], [board], [nuttx] structure >> > – how to set up your own board >> > These questions are recurring. They were asked on the mailing list >> recently >> > again. They are basic things and they should be the second page of >> > documentation. >> > b) Typical policy for documentation is that when people ask, the >> > answer >> > should be put to documentation and the link sent back as an answer. >> > c) Table of supported features on different platforms and boards, as >> > discussed recently. For people who want to use NuttX to feel safe and >> know >> > how much they need to contribute to make their project work. >> >> Completely agree on the above. I would add that when people add a new >> board they document it >> following a set of guidelines (maybe based on a template). Also, new >> features or breaking changes >> should be accompanied by documentation changes. Distributing the load on >> maintaining the documentation >> IMHO is the way to keep it updated. >> >> > 2) Package management >> > Database where people can submit whatever they want, as long as it >> > works >> > and they are willing to maintain it. >> > Description on what such packages need to fulfill to work with NuttX. >> Some >> > simple command line tool to inject packages to NuttX projects. >> >> On my "NuttX workspace manager" ( >> https://gitlab.com/nuttx_projects/nuttx_workspace_manager) I have this >> mechanism that allows you to simply drop a directory containing an app >> inside an "extra_apps" directory. This works >> by having a symlink from apps/external point to this directory, where >> NuttX looks for external apps. The trick is to >> have a Make.defs recursively including Make.defs from subdirectories and >> a >> Makefile including "Directory.mk". This are the files that are placed >> inside extra_apps/: >> https://gitlab.com/nuttx_projects/nuttx_workspace_manager/-/tree/master/files/extra_apps. >> If external/ would already have this set up, it would indeed be a matter >> of >> dropping an app there. >> >> Furthermore, I personally like to use submodules but even if you simply >> clone or download a git repo containing just the app, you wouldn't need a >> central database of apps, just a git repo for each app. If some sort of >> "central repository" is desired, a special github organization could be >> used to collect contributed apps. >> >> I have a similar mechanism for OS level code, which is compiled as if it >> were a subdirectory of nuttx/. >> >> Best, >> Matias >> >> > Am Mi., 5. Aug. 2020 um 17:20 Uhr schrieb Xiang Xiao < >> > xiaoxiang781...@gmail.com>: >> > >> > > I would see the automation test on the roadmap, thanks. >> > > >> > > > -Original Message- >> > > > From: Matias N. >> > > > Sent: Wednesday, August 5, 2020 4:59 AM >> > > > To: dev@nuttx.apache.org >> > > > Subject: Re: Roadmap? >> > > > >> > > > Having a (public) roadmap is very good idea, it guides and >> > > > organizes >> > > efforts over time and also gives indication to existing or >> > > potential >> > > > users about which features which are not currently but might as >> > > > well >> be >>
Re: Roadmap?
If we create issues as a first step, we can identify who will be responsible for driving that effort forward. The issue can then be assigned to that person and the issue updated to reflect progress. The issue can be assigned a GitHub milestone (a way to group issues together, with an optional targeted date) corresponding to a given minor or major release (or "future" to signify we do not know when we would like to introduce this into NuttX). On each issue we can also identify how disruptive this feature is and thus when does it sound reasonable to add it (next minor release? next major release? even further ahead?). Things can be bumped to later milestones if needed. Having this setup, if desired, a Roadmap document can be written to publicize this more clearly. > Where would we document a roadmap? How/who would prioritize and > schedule implementation of roadmap items? How could accomplish any of > this with only a volunteer organization and no project management with > any authority? > > >
Re: Roadmap?
> Where would we document a roadmap? How/who would prioritize and > schedule implementation of roadmap items? How could accomplish any of > this with only a volunteer organization and no project management with > any authority? We can loosely define a release cycle, e.g. 3 months. At the start of every cycle, we get all bugs and security issues. Then, depending on the estimated workload, we discuss/vote on new features to be included in this release cycle. We can also make it easier by defining the priority of the issues, depending on the impact on the project. I would prioritize issues related to the kernel first, then arch support, then drivers, then external libraries/apps. Στις Τετ, 12 Αυγ 2020 στις 7:23 μ.μ., ο/η David Sidrane < david.sidr...@nscdg.com> έγραψε: > Github project boards or confluence? > > -Original Message- > From: Gregory Nutt [mailto:spudan...@gmail.com] > Sent: Wednesday, August 12, 2020 9:07 AM > To: dev@nuttx.apache.org > Subject: Re: Roadmap? > > > > I am interested in industrial devices communicating by fieldbuses. I use > > the NuttX port of FreeModbus stack and I would like to see more port of > > communication stacks like this. I prefer CANopen and Profinet, There are > > several open source communication stack for these protocols. > > Where would we document a roadmap? How/who would prioritize and > schedule implementation of roadmap items? How could accomplish any of > this with only a volunteer organization and no project management with > any authority? >
RE: Roadmap?
Github project boards or confluence? -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Wednesday, August 12, 2020 9:07 AM To: dev@nuttx.apache.org Subject: Re: Roadmap? > I am interested in industrial devices communicating by fieldbuses. I use > the NuttX port of FreeModbus stack and I would like to see more port of > communication stacks like this. I prefer CANopen and Profinet, There are > several open source communication stack for these protocols. Where would we document a roadmap? How/who would prioritize and schedule implementation of roadmap items? How could accomplish any of this with only a volunteer organization and no project management with any authority?
Re: Roadmap?
Should we start creating issues for these ideas and start assigning them to milestones? The initial milestone could be "future" so that we can later decide on a given version to target. On Wed, Aug 12, 2020, at 13:03, Matous Pokorny wrote: > Hello! > > I definitely agree with all the words written below and I would like to add > few wishes. > > I am interested in industrial devices communicating by fieldbuses. I use > the NuttX port of FreeModbus stack and I would like to see more port of > communication stacks like this. I prefer CANopen and Profinet, There are > several open source communication stack for these protocols. > > Thank you and have a nice day. > _ > *Matouš Pokorný* | Embedded system developer > DataVision s.r.o. | Czech Republic > > st 5. 8. 2020 v 18:48 odesílatel Matias N. napsal: > > > On Wed, Aug 5, 2020, at 13:35, Maciej Wójcik wrote: > > > 1) More opinionated documentation > > > a) In particular clear instructions: > > > – where to get compilers for C/C++ > > > – how to setup project with an application outside of nuttx, and > > clear > > > [apps], [libs], [board], [nuttx] structure > > > – how to set up your own board > > > These questions are recurring. They were asked on the mailing list > > recently > > > again. They are basic things and they should be the second page of > > > documentation. > > > b) Typical policy for documentation is that when people ask, the answer > > > should be put to documentation and the link sent back as an answer. > > > c) Table of supported features on different platforms and boards, as > > > discussed recently. For people who want to use NuttX to feel safe and > > know > > > how much they need to contribute to make their project work. > > > > Completely agree on the above. I would add that when people add a new > > board they document it > > following a set of guidelines (maybe based on a template). Also, new > > features or breaking changes > > should be accompanied by documentation changes. Distributing the load on > > maintaining the documentation > > IMHO is the way to keep it updated. > > > > > 2) Package management > > > Database where people can submit whatever they want, as long as it works > > > and they are willing to maintain it. > > > Description on what such packages need to fulfill to work with NuttX. > > Some > > > simple command line tool to inject packages to NuttX projects. > > > > On my "NuttX workspace manager" ( > > https://gitlab.com/nuttx_projects/nuttx_workspace_manager) I have this > > mechanism that allows you to simply drop a directory containing an app > > inside an "extra_apps" directory. This works > > by having a symlink from apps/external point to this directory, where > > NuttX looks for external apps. The trick is to > > have a Make.defs recursively including Make.defs from subdirectories and a > > Makefile including "Directory.mk". This are the files that are placed > > inside extra_apps/: > > https://gitlab.com/nuttx_projects/nuttx_workspace_manager/-/tree/master/files/extra_apps. > > If external/ would already have this set up, it would indeed be a matter of > > dropping an app there. > > > > Furthermore, I personally like to use submodules but even if you simply > > clone or download a git repo containing just the app, you wouldn't need a > > central database of apps, just a git repo for each app. If some sort of > > "central repository" is desired, a special github organization could be > > used to collect contributed apps. > > > > I have a similar mechanism for OS level code, which is compiled as if it > > were a subdirectory of nuttx/. > > > > Best, > > Matias > > > > > Am Mi., 5. Aug. 2020 um 17:20 Uhr schrieb Xiang Xiao < > > > xiaoxiang781...@gmail.com>: > > > > > > > I would see the automation test on the roadmap, thanks. > > > > > > > > > -Original Message- > > > > > From: Matias N. > > > > > Sent: Wednesday, August 5, 2020 4:59 AM > > > > > To: dev@nuttx.apache.org > > > > > Subject: Re: Roadmap? > > > > > > > > > > Having a (public) roadmap is very good idea, it guides and organizes > > > > efforts over time and also gives indication to existing or > > > > potential > > > > > users about which features which are not currently but might a
Re: Roadmap?
I am interested in industrial devices communicating by fieldbuses. I use the NuttX port of FreeModbus stack and I would like to see more port of communication stacks like this. I prefer CANopen and Profinet, There are several open source communication stack for these protocols. Where would we document a roadmap? How/who would prioritize and schedule implementation of roadmap items? How could accomplish any of this with only a volunteer organization and no project management with any authority?
Re: Roadmap?
Hello! I definitely agree with all the words written below and I would like to add few wishes. I am interested in industrial devices communicating by fieldbuses. I use the NuttX port of FreeModbus stack and I would like to see more port of communication stacks like this. I prefer CANopen and Profinet, There are several open source communication stack for these protocols. Thank you and have a nice day. _ *Matouš Pokorný* | Embedded system developer DataVision s.r.o. | Czech Republic st 5. 8. 2020 v 18:48 odesílatel Matias N. napsal: > On Wed, Aug 5, 2020, at 13:35, Maciej Wójcik wrote: > > 1) More opinionated documentation > > a) In particular clear instructions: > > – where to get compilers for C/C++ > > – how to setup project with an application outside of nuttx, and > clear > > [apps], [libs], [board], [nuttx] structure > > – how to set up your own board > > These questions are recurring. They were asked on the mailing list > recently > > again. They are basic things and they should be the second page of > > documentation. > > b) Typical policy for documentation is that when people ask, the answer > > should be put to documentation and the link sent back as an answer. > > c) Table of supported features on different platforms and boards, as > > discussed recently. For people who want to use NuttX to feel safe and > know > > how much they need to contribute to make their project work. > > Completely agree on the above. I would add that when people add a new > board they document it > following a set of guidelines (maybe based on a template). Also, new > features or breaking changes > should be accompanied by documentation changes. Distributing the load on > maintaining the documentation > IMHO is the way to keep it updated. > > > 2) Package management > > Database where people can submit whatever they want, as long as it works > > and they are willing to maintain it. > > Description on what such packages need to fulfill to work with NuttX. > Some > > simple command line tool to inject packages to NuttX projects. > > On my "NuttX workspace manager" ( > https://gitlab.com/nuttx_projects/nuttx_workspace_manager) I have this > mechanism that allows you to simply drop a directory containing an app > inside an "extra_apps" directory. This works > by having a symlink from apps/external point to this directory, where > NuttX looks for external apps. The trick is to > have a Make.defs recursively including Make.defs from subdirectories and a > Makefile including "Directory.mk". This are the files that are placed > inside extra_apps/: > https://gitlab.com/nuttx_projects/nuttx_workspace_manager/-/tree/master/files/extra_apps. > If external/ would already have this set up, it would indeed be a matter of > dropping an app there. > > Furthermore, I personally like to use submodules but even if you simply > clone or download a git repo containing just the app, you wouldn't need a > central database of apps, just a git repo for each app. If some sort of > "central repository" is desired, a special github organization could be > used to collect contributed apps. > > I have a similar mechanism for OS level code, which is compiled as if it > were a subdirectory of nuttx/. > > Best, > Matias > > > Am Mi., 5. Aug. 2020 um 17:20 Uhr schrieb Xiang Xiao < > > xiaoxiang781...@gmail.com>: > > > > > I would see the automation test on the roadmap, thanks. > > > > > > > -Original Message- > > > > From: Matias N. > > > > Sent: Wednesday, August 5, 2020 4:59 AM > > > > To: dev@nuttx.apache.org > > > > Subject: Re: Roadmap? > > > > > > > > Having a (public) roadmap is very good idea, it guides and organizes > > > efforts over time and also gives indication to existing or > > > potential > > > > users about which features which are not currently but might as well > be > > > there soon. > > > > > > > > I personally would like to see support for Bluetooth/WiFi on widely > used > > > hardware platforms. > > > > I'm currently working on getting BLE on nRF working so it is a > matter of > > > time. I hope that also Alan might steer Espressif into > > > add > > > > support for ESP32. LoRaWAN stack would also be interesting. > > > > I would also add the current documentation effort as part of the > roadmap. > > > > > > > > I think with a Roadmap laid out it would be possible to create GitHub > > > milestones (major and min
Re: Roadmap?
On Wed, Aug 5, 2020, at 13:35, Maciej Wójcik wrote: > 1) More opinionated documentation > a) In particular clear instructions: > – where to get compilers for C/C++ > – how to setup project with an application outside of nuttx, and clear > [apps], [libs], [board], [nuttx] structure > – how to set up your own board > These questions are recurring. They were asked on the mailing list recently > again. They are basic things and they should be the second page of > documentation. > b) Typical policy for documentation is that when people ask, the answer > should be put to documentation and the link sent back as an answer. > c) Table of supported features on different platforms and boards, as > discussed recently. For people who want to use NuttX to feel safe and know > how much they need to contribute to make their project work. Completely agree on the above. I would add that when people add a new board they document it following a set of guidelines (maybe based on a template). Also, new features or breaking changes should be accompanied by documentation changes. Distributing the load on maintaining the documentation IMHO is the way to keep it updated. > 2) Package management > Database where people can submit whatever they want, as long as it works > and they are willing to maintain it. > Description on what such packages need to fulfill to work with NuttX. Some > simple command line tool to inject packages to NuttX projects. On my "NuttX workspace manager" (https://gitlab.com/nuttx_projects/nuttx_workspace_manager) I have this mechanism that allows you to simply drop a directory containing an app inside an "extra_apps" directory. This works by having a symlink from apps/external point to this directory, where NuttX looks for external apps. The trick is to have a Make.defs recursively including Make.defs from subdirectories and a Makefile including "Directory.mk". This are the files that are placed inside extra_apps/: https://gitlab.com/nuttx_projects/nuttx_workspace_manager/-/tree/master/files/extra_apps. If external/ would already have this set up, it would indeed be a matter of dropping an app there. Furthermore, I personally like to use submodules but even if you simply clone or download a git repo containing just the app, you wouldn't need a central database of apps, just a git repo for each app. If some sort of "central repository" is desired, a special github organization could be used to collect contributed apps. I have a similar mechanism for OS level code, which is compiled as if it were a subdirectory of nuttx/. Best, Matias > Am Mi., 5. Aug. 2020 um 17:20 Uhr schrieb Xiang Xiao < > xiaoxiang781...@gmail.com>: > > > I would see the automation test on the roadmap, thanks. > > > > > -Original Message- > > > From: Matias N. > > > Sent: Wednesday, August 5, 2020 4:59 AM > > > To: dev@nuttx.apache.org > > > Subject: Re: Roadmap? > > > > > > Having a (public) roadmap is very good idea, it guides and organizes > > efforts over time and also gives indication to existing or > > potential > > > users about which features which are not currently but might as well be > > there soon. > > > > > > I personally would like to see support for Bluetooth/WiFi on widely used > > hardware platforms. > > > I'm currently working on getting BLE on nRF working so it is a matter of > > time. I hope that also Alan might steer Espressif into > > add > > > support for ESP32. LoRaWAN stack would also be interesting. > > > I would also add the current documentation effort as part of the roadmap. > > > > > > I think with a Roadmap laid out it would be possible to create GitHub > > milestones (major and minor) and organize issues into each, > > > depending on how disruptive the change is. This would help to have for > > example a 10.x series more or less stable while holding > > bigger > > > changes towards 11.0 or even 12.0. > > > > > > Just my two cents. > > > > > > Best, > > > Matias > > > > > > On Tue, Aug 4, 2020, at 17:32, Gregory Nutt wrote: > > > > One of the things that I think we are missing is a Roadmap to guide > > > > and prioritize new feature development. Other RTOS' (like Zephyr) do > > > > have such published roadmaps and are responsive to needs and requests > > > > of users and sponsors. I have even seen web pages where the Zephyr > > > > team has laid out what new features on the roadmap will be available > > > > in future releases. > > > > > > > > While I think it would be e
RE: Roadmap?
I would see the automation test on the roadmap, thanks. > -Original Message- > From: Matias N. > Sent: Wednesday, August 5, 2020 4:59 AM > To: dev@nuttx.apache.org > Subject: Re: Roadmap? > > Having a (public) roadmap is very good idea, it guides and organizes efforts > over time and also gives indication to existing or potential > users about which features which are not currently but might as well be there > soon. > > I personally would like to see support for Bluetooth/WiFi on widely used > hardware platforms. > I'm currently working on getting BLE on nRF working so it is a matter of > time. I hope that also Alan might steer Espressif into add > support for ESP32. LoRaWAN stack would also be interesting. > I would also add the current documentation effort as part of the roadmap. > > I think with a Roadmap laid out it would be possible to create GitHub > milestones (major and minor) and organize issues into each, > depending on how disruptive the change is. This would help to have for > example a 10.x series more or less stable while holding bigger > changes towards 11.0 or even 12.0. > > Just my two cents. > > Best, > Matias > > On Tue, Aug 4, 2020, at 17:32, Gregory Nutt wrote: > > One of the things that I think we are missing is a Roadmap to guide > > and prioritize new feature development. Other RTOS' (like Zephyr) do > > have such published roadmaps and are responsive to needs and requests > > of users and sponsors. I have even seen web pages where the Zephyr > > team has laid out what new features on the roadmap will be available > > in future releases. > > > > While I think it would be essentially impossible for us to manage such > > a thing with our loose organiation, I think we should have a roadmap > > that identifies the important directions that operating system will take. > > > > For me, the important thing is to stay relevant and contemporary and > > not get lost in some aging niche architecture or toolset. I think > > that the best way to predict where NuttX needs to be is to look at the > > SoCs in use just above the upper end of the NuttX market. I think > > over time, those features will trickle down into embedded systems > > (albeit with some twists and modifications for the embedded market). > > The Cortex-M7 introduces I-Cache and L1 D-Cache, for example. A few > > years ago, those were higher end features not available on MCUs. > > > > I think that SMP and AMP are key technologies to get us a leg up on > > future mutli-core MCUs. KERNEL mode places us in a position to > > support MCUs with MMUs. A proper TrustZone model for all ARM parts is > > needed too (the multi-core TrustZone model is pretty well in place, > > but what do we do with TrustZone on a single CPU?). > > > > Security, especially IoT security is very important. Some security > > topics are addressed by PROTECTED mode. So although PROTECTED and > > KERNEL build modes are not commonly used, I believe that they are > > important parts of the roadmap. > > > > Other thoughts? We should collaborate and define a meaningful > > roadmap that will keep the OS healthy well into the future. We should > > publish that roadmap somewhere so that anyone can see where we are > > going and can offer insights for other directions. > > > > > >
Re: Roadmap?
Having a (public) roadmap is very good idea, it guides and organizes efforts over time and also gives indication to existing or potential users about which features which are not currently but might as well be there soon. I personally would like to see support for Bluetooth/WiFi on widely used hardware platforms. I'm currently working on getting BLE on nRF working so it is a matter of time. I hope that also Alan might steer Espressif into add support for ESP32. LoRaWAN stack would also be interesting. I would also add the current documentation effort as part of the roadmap. I think with a Roadmap laid out it would be possible to create GitHub milestones (major and minor) and organize issues into each, depending on how disruptive the change is. This would help to have for example a 10.x series more or less stable while holding bigger changes towards 11.0 or even 12.0. Just my two cents. Best, Matias On Tue, Aug 4, 2020, at 17:32, Gregory Nutt wrote: > One of the things that I think we are missing is a Roadmap to guide and > prioritize new feature development. Other RTOS' (like Zephyr) do have > such published roadmaps and are responsive to needs and requests of > users and sponsors. I have even seen web pages where the Zephyr team > has laid out what new features on the roadmap will be available in > future releases. > > While I think it would be essentially impossible for us to manage such a > thing with our loose organiation, I think we should have a roadmap that > identifies the important directions that operating system will take. > > For me, the important thing is to stay relevant and contemporary and not > get lost in some aging niche architecture or toolset. I think that the > best way to predict where NuttX needs to be is to look at the SoCs in > use just above the upper end of the NuttX market. I think over time, > those features will trickle down into embedded systems (albeit with some > twists and modifications for the embedded market). The Cortex-M7 > introduces I-Cache and L1 D-Cache, for example. A few years ago, those > were higher end features not available on MCUs. > > I think that SMP and AMP are key technologies to get us a leg up on > future mutli-core MCUs. KERNEL mode places us in a position to support > MCUs with MMUs. A proper TrustZone model for all ARM parts is needed > too (the multi-core TrustZone model is pretty well in place, but what do > we do with TrustZone on a single CPU?). > > Security, especially IoT security is very important. Some security > topics are addressed by PROTECTED mode. So although PROTECTED and > KERNEL build modes are not commonly used, I believe that they are > important parts of the roadmap. > > Other thoughts? We should collaborate and define a meaningful roadmap > that will keep the OS healthy well into the future. We should publish > that roadmap somewhere so that anyone can see where we are going and can > offer insights for other directions. > > >
Roadmap?
One of the things that I think we are missing is a Roadmap to guide and prioritize new feature development. Other RTOS' (like Zephyr) do have such published roadmaps and are responsive to needs and requests of users and sponsors. I have even seen web pages where the Zephyr team has laid out what new features on the roadmap will be available in future releases. While I think it would be essentially impossible for us to manage such a thing with our loose organiation, I think we should have a roadmap that identifies the important directions that operating system will take. For me, the important thing is to stay relevant and contemporary and not get lost in some aging niche architecture or toolset. I think that the best way to predict where NuttX needs to be is to look at the SoCs in use just above the upper end of the NuttX market. I think over time, those features will trickle down into embedded systems (albeit with some twists and modifications for the embedded market). The Cortex-M7 introduces I-Cache and L1 D-Cache, for example. A few years ago, those were higher end features not available on MCUs. I think that SMP and AMP are key technologies to get us a leg up on future mutli-core MCUs. KERNEL mode places us in a position to support MCUs with MMUs. A proper TrustZone model for all ARM parts is needed too (the multi-core TrustZone model is pretty well in place, but what do we do with TrustZone on a single CPU?). Security, especially IoT security is very important. Some security topics are addressed by PROTECTED mode. So although PROTECTED and KERNEL build modes are not commonly used, I believe that they are important parts of the roadmap. Other thoughts? We should collaborate and define a meaningful roadmap that will keep the OS healthy well into the future. We should publish that roadmap somewhere so that anyone can see where we are going and can offer insights for other directions.
Re: Question about structure roadmap
Hi, . > That's basically true of IRC, conference call, or any real time > communication. > Email has many advantages: - it allows anyone not matter their day job or time zone to take part - it tends to have a higher ratio of informational content - its easily searchable and archived - it has subjects so you skim to see what to read - it's threaded - users have choice of clients with many features including smart ways of marking or grouping messages Maybe we can have the slack or whichever medium, but when there is going to > be a meeting there, post about it to the mailing list so others who might > be interested could have a chance? > Some may still be unable to attend so it best if a summary be brought back to the list. Given the choice of attending a metering and reading a good summary I know what I would choose. :-) Thanks, Justin
Re: Question about structure roadmap
On Sun, Dec 15, 2019 at 5:29 PM Gregory Nutt wrote: > > >> I created a #nuttx Slack channel in the ASF Slack. My understanding is > >> that anyone can join a single channel even if you are not a project > member. > > If I may... I'm not sure that's such a great idea. > > > > I'm open to reconsider if there's a reason to have a slack that I'm > > not seeing, but I think it could cause trouble. > > > > Reasoning: It splits our communications. I'd rather consolidate, not > split... > > Slack is useful for certain kinds of activities such as focusing on > working through technical issues. It is great for that fast > brainstorming to work through technical issues. Using it as a > substitute for email is not so good. > > The only negative thing I recall Justin saying about Slack is that is > doesn't work so good across large time zones. That's basically true of IRC, conference call, or any real time communication. I agree it can be good if you really need to focus on some specific thing with a particular person and you can coordinate. Maybe we can have the slack or whichever medium, but when there is going to be a meeting there, post about it to the mailing list so others who might be interested could have a chance? Just a thought Nathan
Re: Question about structure roadmap
On Sun, Dec 15, 2019 at 5:12 PM Gregory Nutt wrote: > > Apache supports a Slack. But it is only available for posting by > > project members. > > https://cwiki.apache.org/confluence/display/INFRA/Slack+Guest+Invites > > No members can join into a single channel, but I am not sure exactly > > how that works. The sign-up is here http://s.apache.org/slack-invite > > I created a #nuttx Slack channel in the ASF Slack. My understanding is > that anyone can join a single channel even if you are not a project member. If I may... I'm not sure that's such a great idea. I'm open to reconsider if there's a reason to have a slack that I'm not seeing, but I think it could cause trouble. Reasoning: It splits our communications. I'd rather consolidate, not split... Thoughts? Nathan
Re: Question about structure roadmap
Apache supports a Slack. But it is only available for posting by project members. https://cwiki.apache.org/confluence/display/INFRA/Slack+Guest+Invites No members can join into a single channel, but I am not sure exactly how that works. The sign-up is here http://s.apache.org/slack-invite I created a #nuttx Slack channel in the ASF Slack. My understanding is that anyone can join a single channel even if you are not a project member. NOTE: The reason that only project members are support is because this is the paid slack which costs somewhere betwee 3 and 4 dollars per person per month. Hmmm... It never asked my any project credentials when I signed up Greg
Re: Question about structure roadmap
I would rather use an IRC channel than slack :p Where is this channel? Freenode? #nuttx ? Sebastien On 12/15/19 11:05 PM, Gregory Nutt wrote: Communication stuff I still see the slack channels, but they will go away? The IRC channel will get back up in IRC apache? Linked in yes no? What the communication plan??! Slack is shutting down. I tried to login earlier to deactivate myself and it turns out that I was already deactivated. So it might be gone already. Any member listed as inactive (meaning they are not actively using Slack) get deactivated. When all members are deactivated, Slack will disappear. You may as well stop using Slack. There will not be anything there to talk to and no one will read the posts. That would be helpful. Apache supports a Slack. But it is only available for posting by project members. https://cwiki.apache.org/confluence/display/INFRA/Slack+Guest+Invites No members can join into a single channel, but I am not sure exactly how that works. The sign-up is here http://s.apache.org/slack-invite I don't think IRC plans were discussed at all. We should start a separate thread about that too. Do people still use the IRC channel? I haven't been there is months, maybe years.
Re: Question about structure roadmap
Communication stuff I still see the slack channels, but they will go away? The IRC channel will get back up in IRC apache? Linked in yes no? What the communication plan??! Slack is shutting down. I tried to login earlier to deactivate myself and it turns out that I was already deactivated. So it might be gone already. Any member listed as inactive (meaning they are not actively using Slack) get deactivated. When all members are deactivated, Slack will disappear. You may as well stop using Slack. There will not be anything there to talk to and no one will read the posts. That would be helpful. Apache supports a Slack. But it is only available for posting by project members. https://cwiki.apache.org/confluence/display/INFRA/Slack+Guest+Invites No members can join into a single channel, but I am not sure exactly how that works. The sign-up is here http://s.apache.org/slack-invite I don't think IRC plans were discussed at all. We should start a separate thread about that too. Do people still use the IRC channel? I haven't been there is months, maybe years.
Re: Question about structure roadmap
On Sun, Dec 15, 2019 at 3:34 AM Disruptive Solutions wrote: > > Its a bit messy on the mail right now... (And maybe its only my feeling then > please do nothing with my question/signal). Yes. We need to get accustomed to the new way of doing things... I think the key is to keep one thread per topic, and one topic per thread. More below: > Contribute patches > If and how I contribute is not clear for me at this moment. I have to sign a > paper ICLA and scan it and send it to? The patch process seemed to work.. > does this process stay? We need to start a thread to discuss this particular issue. Do we accept patches only? GitHub Pull Requests only? Both patches and pull requests? Are there any other methods to receive changes? Would you like to go ahead and start such a thread? > Communication stuff > I still see the slack channels, but they will go away? The IRC channel will > get back up in IRC apache? Linked in yes no? What the communication plan??! Slack is shutting down. I tried to login earlier to deactivate myself and it turns out that I was already deactivated. So it might be gone already. I think most communication will take place on this dev@ list for the near future. LinkedIn, as far as I know, is staying but only for announcements. It already has 1000 followers I'm told, who stay tuned for announcements etc. Someone (maybe it was Justin?) pointed out that many Apache projects have FaceBook, Twitter, etc., social media sites, so it's normal to keep LinkedIn. I don't think IRC plans were discussed at all. We should start a separate thread about that too. > Insight > Can someone make things more clear by making a roadmap or something? I hope I was somewhat helpful. Feel free to discuss any and all issues about NuttX here on this list, whether technical, management of the project, etc. Nathan
Re: Question about structure roadmap
Hi, Some chaos was expected. The project is still on the road of moving. The main communication channel is the dev list now. The google group is still operational but that won't be for too long. It will either get archived or posters will be redirected to the dev mailing list.. The Slack channel will likely go away. Changes are still accepted on the Bitbucket repositories until the Apache ones are up and running. I don't think you need to sign an ICLA to be able to contribute. (Please see also the thread "ICLA needed?") On Sun, Dec 15, 2019 at 9:41 AM Justin Mclean wrote: > > Hi, > > > Can someone make things more clear by making a roadmap or something? > > It’s up to the PMC to discuss and do this. I think more discussion need to happen on this issues on this list. > > Thanks, > Justin
