Re: Contributions (PR or patches)
Hi, > Things are a bit different in ASF as we can use jenkins instead of travis ci. Other CIs are available, but jenkins is probably he most widely used one. Thanks, Justin
Re: Contributions (PR or patches)
Hi, > I am just wondering if we are excluding any users by forcing everyone to use > PRs. In my experience there are people why will refuse to use GitHub (because of reasons), they may however still use git. Thanks, Justin
Fwd: Add some instructions or make the link available on Nuttx home page
JFYI > Begin forwarded message: > > From: jincheng sun > Subject: Add some instructions or make the link available on Nuttx home page > Date: 16 December 2019 at 6:07:28 pm AEDT > To: gene...@incubator.apache.org > Reply-To: gene...@incubator.apache.org > > I found there is a link of NuttX is not work in home page of `apache.org`[1]. > So, I create a JIRA for this issue [2]. But I found is not the issue for ` > apache.org` but something worng in NuttX home page [3]. I do not know how > to deal with this kind of problems, so, report the problems in this > maillist. > > Best, > Jincheng > > [1] http://apache.org/ > [2] https://issues.apache.org/jira/browse/INFRA-19576 > [3] http://incubator.apache.org/projects/nuttx.html
Re: [nuttx] Wiki Backup
Ok, That was a bigger hassle than I expected. The converter tool was getting tripped up with odd escaping and generating bad XML files for confluence, but I think it is good now. I also went through and manually cleaned the naming, obvious issues, and inserted a bunch of confluence macros on the pages. https://cwiki.apache.org/confluence/display/NUTTXTEST/Nuttx I think it is good to go live, but there are a few things to address: 1) There are some links that were not wiki links, but url links to the wiki that did not get converted. I have the sources to find all of these, so I will tackle that soon. 2a) The documentation pages are embedding the HTML documentation that is on nuttx.org/Documentation but once the code is moved to github/apache I will update to pull the latest. 2b) The documentation is using favicons internally as images, this is not valid and causes issues broken image links. This should be fixed in the code no changes are needed on the wiki. 3) The presentations are linked to pdfs at nuttx.org Those PDFs should just become attachments to wiki pages. Justin if you move this to NUTTX from NUTTXTEST please add me to the permissions on that space as well. Thanks, Brennan On Sun, Dec 15, 2019 at 4:27 PM Gregory Nutt wrote: > > > First stab at the import went surprisingly well. All but a few pages > > converted, unfortunately the hierarchy did not convert correctly so I > will > > have to mess with it more (these tools are mostly abandoned for 8+ years > so > > at least they run). > That is good news. > > Greg I dont think I will need the other non wiki files since they were > not > > wiki attachments they are just external links, we will just have to > > manually re-import them which should be easy enough. > > I am about ready to go upstairs where the internet is good and I will > still transfer them. They might come in handy for you. > > Greg > > > >
Re: Contributions (PR or patches)
Things are a bit different in ASF as we can use jenkins instead of travis ci. If the code is ready on github, I could help setting up the jenkins job to pull PR as I've done this for other ASF projects in the past. Thanks. Xiang Xiao 于2019年12月16日周一 上午11:35写道： > Yes, GitHub has the standard workflow, we just need insert our special > requirement(style, build and test) into it: > > https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/github-flow > Here is one example mynewt: > https://github.com/apache/mynewt-core/pull/2126 > > Thanks > Xiang > On Mon, Dec 16, 2019 at 10:56 AM Nathan Hartman > wrote: > > > > On Sun, Dec 15, 2019 at 9:12 PM Gregory Nutt > wrote: > > > > > Sorry to keep running on... > > > > > > Another thing is that we do not want dictate to uses of release what > > > configuration management tools they must use. In our open source > > > culture, GIT is pervasive, but remember that many corporations prefer > > > commercial SCM systems. > > > > > > Case in point: My $company uses a really awesome SCM: Apache Subversion > :-) > > > > So the process is something along these lines: > > > > (Please fill in any gaps...) > > > > Will we receive a patch, which I'm assuming will come to dev@ in the > form > > of email attachments, then a NuttX committer looks at it, sees if it > looks > > reasonable, then converts that into a GitHub PR. > > > > Which begs the question: how do we keep track of emailed patches being > > processed? Perhaps as simple as a committer replying to the email to say > > that it's being processed? > > > > Once at GitHub then automated tests run (including nxstyle), then ... ??? > > > > In certain parts of the system, I think we should have reasonably low > > barriers to getting contributions in. Drivers for adding, say, SPI > support > > to some chip shouldn't require too much scrutiny provided they meet the > > coding standard... > > > > But: > > > > In some critical parts, including the build system and OS internals like > > the scheduler, we need a process whereby several pairs of eyes will look > at > > the PR and agree that it should be merged. For example, say, we need N > +1s > > and zero -1s for any changes that affect those parts... (the value of N > > will need discussion but that is a subject for another day). > > > > So, how will we keep track of approvals? I assume that GitHub has a built > > in mechanism for this purpose? > > > > Nathan >
Re: Contributions (PR or patches)
Yes, GitHub has the standard workflow, we just need insert our special requirement(style, build and test) into it: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/github-flow Here is one example mynewt: https://github.com/apache/mynewt-core/pull/2126 Thanks Xiang On Mon, Dec 16, 2019 at 10:56 AM Nathan Hartman wrote: > > On Sun, Dec 15, 2019 at 9:12 PM Gregory Nutt wrote: > > > Sorry to keep running on... > > > > Another thing is that we do not want dictate to uses of release what > > configuration management tools they must use. In our open source > > culture, GIT is pervasive, but remember that many corporations prefer > > commercial SCM systems. > > > Case in point: My $company uses a really awesome SCM: Apache Subversion :-) > > So the process is something along these lines: > > (Please fill in any gaps...) > > Will we receive a patch, which I'm assuming will come to dev@ in the form > of email attachments, then a NuttX committer looks at it, sees if it looks > reasonable, then converts that into a GitHub PR. > > Which begs the question: how do we keep track of emailed patches being > processed? Perhaps as simple as a committer replying to the email to say > that it's being processed? > > Once at GitHub then automated tests run (including nxstyle), then ... ??? > > In certain parts of the system, I think we should have reasonably low > barriers to getting contributions in. Drivers for adding, say, SPI support > to some chip shouldn't require too much scrutiny provided they meet the > coding standard... > > But: > > In some critical parts, including the build system and OS internals like > the scheduler, we need a process whereby several pairs of eyes will look at > the PR and agree that it should be merged. For example, say, we need N +1s > and zero -1s for any changes that affect those parts... (the value of N > will need discussion but that is a subject for another day). > > So, how will we keep track of approvals? I assume that GitHub has a built > in mechanism for this purpose? > > Nathan
Re: Contributions (PR or patches)
Case in point: My $company uses a really awesome SCM: Apache Subversion :-) All very large corporations I have worked for use commercial SCM suites. GIT is a great thing for open source projects and small businesses, but for those companies with essentially unlimited resources you will often see very different commercial tools .. and also RTOSs 8( So the process is something along these lines: (Please fill in any gaps...) Will we receive a patch, which I'm assuming will come to dev@ in the form of email attachments, then a NuttX committer looks at it, sees if it looks reasonable, then converts that into a GitHub PR. Or would we take PRs. PRs would, mostly likely, be directly against the master. Is that an issue? Would we merge patches onto master? Or onto a development branch? What would be do with PRs against master? One problem with patches is the they have dependencies. Applying one patch, may cause a subsequent patch that affects the same file to fail to apply. The solution would be to put each patch on a branch so that it can be merged back in without conflicts (or at least with conflicts that can be resolved with GIT help). We need to spell out the branching. Which begs the question: how do we keep track of emailed patches being processed? Perhaps as simple as a committer replying to the email to say that it's being processed? Is Jira an option? Once at GitHub then automated tests run (including nxstyle), then ... ??? In certain parts of the system, I think we should have reasonably low barriers to getting contributions in. Drivers for adding, say, SPI support to some chip shouldn't require too much scrutiny provided they meet the coding standard... But: In some critical parts, including the build system and OS internals like the scheduler, we need a process whereby several pairs of eyes will look at the PR and agree that it should be merged. For example, say, we need N +1s and zero -1s for any changes that affect those parts... (the value of N will need discussion but that is a subject for another day). +1 Changes to "leaf" software can not create widespread problems but still need to be taken seriously. Greg
Re: Contributions (PR or patches)
On Sun, Dec 15, 2019 at 9:12 PM Gregory Nutt wrote: > Sorry to keep running on... > > Another thing is that we do not want dictate to uses of release what > configuration management tools they must use. In our open source > culture, GIT is pervasive, but remember that many corporations prefer > commercial SCM systems. Case in point: My $company uses a really awesome SCM: Apache Subversion :-) So the process is something along these lines: (Please fill in any gaps...) Will we receive a patch, which I'm assuming will come to dev@ in the form of email attachments, then a NuttX committer looks at it, sees if it looks reasonable, then converts that into a GitHub PR. Which begs the question: how do we keep track of emailed patches being processed? Perhaps as simple as a committer replying to the email to say that it's being processed? Once at GitHub then automated tests run (including nxstyle), then ... ??? In certain parts of the system, I think we should have reasonably low barriers to getting contributions in. Drivers for adding, say, SPI support to some chip shouldn't require too much scrutiny provided they meet the coding standard... But: In some critical parts, including the build system and OS internals like the scheduler, we need a process whereby several pairs of eyes will look at the PR and agree that it should be merged. For example, say, we need N +1s and zero -1s for any changes that affect those parts... (the value of N will need discussion but that is a subject for another day). So, how will we keep track of approvals? I assume that GitHub has a built in mechanism for this purpose? Nathan
Re: Contributions (PR or patches)
But I think that someone from committer need convert patch to the github pull request, and then pass all automatic check before submitting the change. To ensure the commit quality, nobody can bypass the workflow we will setup. You are absolutely right. There is not difference between accepting a patch vs a PR is that the patch must be applied and committed. After that, it does not matter how the commit got there.
Re: Contributions (PR or patches)
Sorry to keep running on... Another thing is that we do not want dictate to uses of release what configuration management tools they must use. In our open source culture, GIT is pervasive, but remember that many corporations prefer commercial SCM systems. I don't think anything about the usage case of NuttX should depend upon particular tools in the user environment (other than those minimal tools necessary for the build). Forcing GIT on everyone would lose some users. Greg On 12/15/2019 7:48 PM, Gregory Nutt wrote: Just a guess, but I think right now we receive 50 or so patches for each PR. That is very deeply ingrained in NuttX userland. On 12/15/2019 7:45 PM, Gregory Nutt wrote: I am just wondering if we are excluding any users by forcing everyone to use PRs. I personally don't have problems with mixed PRs and patches, provided that the patches apply clean. I think we should take the side of the lowest common denominator user and NOT the point of view that makes our job the slickest. Remember that the majority of NuttX users do not use git at all. They use the release tarballs which have all GIT information stripped out. No GIT and not GIT knowledge is required to use NuttX. I don't know if it is customary to strip GIT out of Apache tarballs, but still we need to accept users that have no GIT skills. It is one of the core principles of NuttX that "all users matter" and that we do nothing to restrict the use of the OS, especially not to make out internal life simpler at the expense of a world of users. We should do the opposite; we should keep the complexit o y inside the project and do all we can to make NuttX accessible to all users. Greg
Re: Contributions (PR or patches)
But I think that someone from committer need convert patch to the github pull request, and then pass all automatic check before submitting the change. To ensure the commit quality, nobody can bypass the workflow we will setup. On Mon, Dec 16, 2019 at 9:48 AM Gregory Nutt wrote: > > Just a guess, but I think right now we receive 50 or so patches for each > PR. That is very deeply ingrained in NuttX userland. > > On 12/15/2019 7:45 PM, Gregory Nutt wrote: > > > >> I am just wondering if we are excluding any users by forcing everyone > >> to use PRs. I personally don't have problems with mixed PRs and > >> patches, provided that the patches apply clean. I think we should > >> take the side of the lowest common denominator user and NOT the point > >> of view that makes our job the slickest. > >> > > Remember that the majority of NuttX users do not use git at all. They > > use the release tarballs which have all GIT information stripped out. > > No GIT and not GIT knowledge is required to use NuttX. I don't know > > if it is customary to strip GIT out of Apache tarballs, but still we > > need to accept users that have no GIT skills. > > > > It is one of the core principles of NuttX that "all users matter" and > > that we do nothing to restrict the use of the OS, especially not to > > make out internal life simpler at the expense of a world of users. We > > should do the opposite; we should keep the complexit o y inside the > > project and do all we can to make NuttX accessible to all users. > > > > Greg > >
Re: Contributions (PR or patches)
Just a guess, but I think right now we receive 50 or so patches for each PR. That is very deeply ingrained in NuttX userland. On 12/15/2019 7:45 PM, Gregory Nutt wrote: I am just wondering if we are excluding any users by forcing everyone to use PRs. I personally don't have problems with mixed PRs and patches, provided that the patches apply clean. I think we should take the side of the lowest common denominator user and NOT the point of view that makes our job the slickest. Remember that the majority of NuttX users do not use git at all. They use the release tarballs which have all GIT information stripped out. No GIT and not GIT knowledge is required to use NuttX. I don't know if it is customary to strip GIT out of Apache tarballs, but still we need to accept users that have no GIT skills. It is one of the core principles of NuttX that "all users matter" and that we do nothing to restrict the use of the OS, especially not to make out internal life simpler at the expense of a world of users. We should do the opposite; we should keep the complexit o y inside the project and do all we can to make NuttX accessible to all users. Greg
Re: Contributions (PR or patches)
I am just wondering if we are excluding any users by forcing everyone to use PRs. I personally don't have problems with mixed PRs and patches, provided that the patches apply clean. I think we should take the side of the lowest common denominator user and NOT the point of view that makes our job the slickest. Remember that the majority of NuttX users do not use git at all. They use the release tarballs which have all GIT information stripped out. No GIT and not GIT knowledge is required to use NuttX. I don't know if it is customary to strip GIT out of Apache tarballs, but still we need to accept users that have no GIT skills. It is one of the core principles of NuttX that "all users matter" and that we do nothing to restrict the use of the OS, especially not to make out internal life simpler at the expense of a world of users. We should do the opposite; we should keep the complexit o y inside the project and do all we can to make NuttX accessible to all users. Greg
Re: Contributions (PR or patches)
I am just wondering if we are excluding any users by forcing everyone to use PRs. I personally don't have problems with mixed PRs and patches, provided that the patches apply clean. I think we should take the side of the lowest common denominator user and NOT the point of view that makes our job the slickest. Greg On 12/15/2019 7:31 PM, Anthony Merlino wrote: As Nathan and others have pointed out, we need to discuss, agree, and document how we would like to accept contributions. I think at most, we should accept patches on the mailing list, and PRs on GitHub. But personally, I think we should only support PRs. I think a unified method for all contributions is desirable and makes the PPMC's lives easier. PRs require less work from committers, and tie into the automated build tools easier. They are way easier to keep track of too - Github just lists them all for us. They also can be reviewed and merged without leaving the browser, assuming the change is valid and the build testing has coverage. What do you think? Best, Anthony
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: [nuttx] Wiki Backup
First stab at the import went surprisingly well. All but a few pages converted, unfortunately the hierarchy did not convert correctly so I will have to mess with it more (these tools are mostly abandoned for 8+ years so at least they run). That is good news. Greg I dont think I will need the other non wiki files since they were not wiki attachments they are just external links, we will just have to manually re-import them which should be easy enough. I am about ready to go upstairs where the internet is good and I will still transfer them. They might come in handy for you. Greg
Re: [nuttx] Wiki Backup
First stab at the import went surprisingly well. All but a few pages converted, unfortunately the hierarchy did not convert correctly so I will have to mess with it more (these tools are mostly abandoned for 8+ years so at least they run). Greg I dont think I will need the other non wiki files since they were not wiki attachments they are just external links, we will just have to manually re-import them which should be easy enough. --Brennan On Sun, Dec 15, 2019 at 3:30 PM Alan Carvalho de Assis wrote: > On 12/15/19, Gregory Nutt wrote: > > > >>> A little off topic: What are going to do with all of those > fragmentary, > >>> unsupported versions of the Wiki in other languages. People got > enthused > >>> to have a copy of the Wiki in there own language, converted a couple of > >>> pages, then wandered off to do some other good deed. > >>> > >>> I don't think they have value as they are. > >> Good question, I don't know if it makes sense to keep the initial i18n > >> wiki work. Well, maybe you can keep it and other people will try to > >> contribute translating more pages. > > > > They have been untouched for what a couple of years now (probably not > > that long). They have NEVER been touched since the initial flurry. It > > is unrealistic at this point to believe someone is going to finish > > them. Possible by unlikely to the extreme. > > > > It is just crap that is carried around and makes the Wiki look > > unprofessional. I would vote to dump or archive them. > > > > True! And in fact the browser nowadays supports to translate from > English to user end language. > > So, I don't think it will be a huge issue if we dump it. > > +1 to dump the translated Wiki. > > BR, > > Alan >
Re: [nuttx] Wiki Backup
On 12/15/19, Gregory Nutt wrote: > >>> A little off topic: What are going to do with all of those fragmentary, >>> unsupported versions of the Wiki in other languages. People got enthused >>> to have a copy of the Wiki in there own language, converted a couple of >>> pages, then wandered off to do some other good deed. >>> >>> I don't think they have value as they are. >> Good question, I don't know if it makes sense to keep the initial i18n >> wiki work. Well, maybe you can keep it and other people will try to >> contribute translating more pages. > > They have been untouched for what a couple of years now (probably not > that long). They have NEVER been touched since the initial flurry. It > is unrealistic at this point to believe someone is going to finish > them. Possible by unlikely to the extreme. > > It is just crap that is carried around and makes the Wiki look > unprofessional. I would vote to dump or archive them. > True! And in fact the browser nowadays supports to translate from English to user end language. So, I don't think it will be a huge issue if we dump it. +1 to dump the translated Wiki. BR, Alan
Re: [nuttx] Wiki Backup
Hi Greg, On 12/15/19, Gregory Nutt wrote: > >> Did you get access? When I try to login, it tell me I don't have >> permission. >> >> So, let see if you get the UWC working converting DocuWiki to Confluence. >> >> I can help organizing the content to create better categories to let >> users find it easily. > > A little off topic: What are going to do with all of those fragmentary, > unsupported versions of the Wiki in other languages. People got enthused > to have a copy of the Wiki in there own language, converted a couple of > pages, then wandered off to do some other good deed. > > I don't think they have value as they are. > Good question, I don't know if it makes sense to keep the initial i18n wiki work. Well, maybe you can keep it and other people will try to contribute translating more pages. BR, Alan
Re: [nuttx] Wiki Backup
Did you get access? When I try to login, it tell me I don't have permission. So, let see if you get the UWC working converting DocuWiki to Confluence. I can help organizing the content to create better categories to let users find it easily. A little off topic: What are going to do with all of those fragmentary, unsupported versions of the Wiki in other languages. People got enthused to have a copy of the Wiki in there own language, converted a couple of pages, then wandered off to do some other good deed. I don't think they have value as they are.
Re: [nuttx] Wiki Backup
Hi Brennan, Did you get access? When I try to login, it tell me I don't have permission. So, let see if you get the UWC working converting DocuWiki to Confluence. I can help organizing the content to create better categories to let users find it easily. BR, Alan On 12/15/19, Gregory Nutt wrote: > On 12/15/2019 3:19 PM, Brennan Ashton wrote: >> Ftp or just a zip is fine. The media can be mixed with the pages or not. >> However it's setup now should be fine. This is what I need from the docs >> of >> the first converter stage. > > I can tar up the data directories, put them in a google drive, and share > it with you. > > Let me look into create an FTP account for you. I am not sure that is > possible. I could possible loan you my password, but that is probably > not such a good practice. > > ... no can do: > > *User ID and Password* – with iPage, there is no need to memorize > multiple login information and passwords (which nowadays become > really hard to manage). Pursuant to iPage’s single-access policy, > the login information and passwords for all iPage services are the > same. No need to register new usernames and passwords. This makes it > much easier to manage your iPage hosting account. > > They make it sound like a feature. if I shared the FTP, I would have to > give you the keys to the entire iPage account. > > Greg > > >
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: [nuttx] Wiki Backup
On 12/15/2019 3:19 PM, Brennan Ashton wrote: Ftp or just a zip is fine. The media can be mixed with the pages or not. However it's setup now should be fine. This is what I need from the docs of the first converter stage. I can tar up the data directories, put them in a google drive, and share it with you. Let me look into create an FTP account for you. I am not sure that is possible. I could possible loan you my password, but that is probably not such a good practice. ... no can do: *User ID and Password* – with iPage, there is no need to memorize multiple login information and passwords (which nowadays become really hard to manage). Pursuant to iPage’s single-access policy, the login information and passwords for all iPage services are the same. No need to register new usernames and passwords. This makes it much easier to manage your iPage hosting account. They make it sound like a feature. if I shared the FTP, I would have to give you the keys to the entire iPage account. Greg
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: File headers on 3rd party files [was Re: ICLA needed?]
I would never permit anything that was not BSD or MIT into the repositories on into the build (and now Apache). It is our policy that there will be no licensing surprises to the end-user. There should be no concerns there. When I did a quick review of the last release I did find one GPL file. But no issue we’ll fix this later and double check the dependancies. And I removed it! It was only needed for a 2000-ish era board: commit 897378bc292fc1ff5bbcd3ba616e2cafb8cd5f90 Author: Gregory Nutt Date: Mon Dec 9 11:29:12 2019 -0600 Remove support for generation of RRLOAD binary files. The RRLOAD binary format was used with Linux BSPs from www.ridgerun.com circa 2000-2001. It is still need by the the c5471 board if that bootloader is used. Removes the CONFIG_RRLOAD_BINARY option and tools/mkimage.sh This change was motivated by the presence of the mkimage.sh file under tools. That is the tool that created the RRLOAD binary format. That bash script has a GPL license and, hence, may not be included in an Apache-licensed project.
Re: Project Emails
hello, I am not favorable personally with submodules. They are a pain to keep in sync across multiple remotes and branches. This was used in the past in NuttX, and it was aborted. Sebastien On 12/13/19 3:28 AM, Anthony Merlino wrote: I think submodules are a good way to go. That would leave us with 3 repos as the core Apache NuttX. One for 'nuttx' which, is Greg suggests, should always be exclusively the OS. One for 'apps'. And one for "linking" them together, and for providing other NuttX infrastructure that may not be appropriate in the core OS repo. [image: photo] *Anthony Merlino* CTO & Co-founder, Verge Aero (609)-319-1399 On Thu, Dec 12, 2019 at 8:17 PM David Sidrane wrote: How about sub modules? We atomically tag across both to keep the project in proper synchronization. David -Original Message- From: Nathan Hartman [mailto:hartman.nat...@gmail.com] Sent: Thursday, December 12, 2019 10:55 AM To: dev@nuttx.apache.org Subject: Re: Project Emails On Thu, Dec 12, 2019 at 1:36 PM Gregory Nutt wrote: A NuttX release consists of two tarballs nuttx/ and apps/. nuttx/ is the operating system proper; apps/ is a collection of applications that may or maynot be used with the operating system proper. These applications including some key things and I think most people want to incorporate some subset of applications into their project. But since the applications are NOT part of the operating system they do need to remain separate. I would argue against trying to merge application code into the operating system. So I think we have to consider these two separate releases. We historically release them together as a matched pair so that the use can be user that they interoperate properly. +1 : I agree that nuttx and apps should stay separate. That begs the question, are we going to have two separate Git repositories? Because Git lacks support for multiple projects in one repository. (There's nothing in Git that prevents you from trying, but Git does not have the features that make the "monorepo"/"megarepo" pattern work; e.g., it does not have sparse/partial working copies or clones. Trying to combine nuttx and apps into one repository would force everyone to clone a lot of content they may not need/want and which may complicate building the RTOS with only their custom applications.) Nathan
Re: [nuttx] Wiki Backup
Ftp or just a zip is fine. The media can be mixed with the pages or not. However it's setup now should be fine. This is what I need from the docs of the first converter stage. --Brennan On Sun, Dec 15, 2019, 1:15 PM Gregory Nutt wrote: > > >> I would be happy to push this forward. If there is a test space I can > give > >> it a go this evening. > > I’ve created a test space for you, if you need another just ask. > > > > https://cwiki.apache.org/confluence/display/NUTTXTEST > > There are only a few things that need to be brought in. From DocuWiki, > there is only data/pages which holds the Wiki .txt files. The only > issue there are the files nuttx.txt which is the landing page and > navigation.txt which is the sidebar. navigation.txt WILL cause some > problems. It uses a sidebar plug-in that no longer exists and can't be > updated. Basically, there will need to be a new sidebar design based on > navigation .txt. > > There are also several directories unrelated to DocuWiki that need to > come along because they include documents and images referenced in > DocuWiki: Images/, Documenation/, Videos/, nxwidgets_v1_19/, > > That is really all you need to know. Will you need FTP access to get > these non-DocuWiki directories? > > >
Re: File headers [was Re: ICLA needed?]
So, could we just remove the original BSD header from Samsung modified files and just keep their Apache license into those file? I don’t recommend we do that as they may of made changes or the files may of changed since they copied them. They probably also used teh 3rd party header not the ASF one. No Samsung files could be brought in until they are made to conform to the NuttX coding standard (Yes, Samsung changed the coding standard too). If they are reconverted to the NuttX standard, it should be pretty easy to see any differences. I think we are talking about a doomsday scenario here. We need to get creative only if there is a snag. Let's assume that there will be no snag (but also be prepared with Plan B). Greg
File headers on 3rd party files [was Re: ICLA needed?]
Hi, > Also, there are no unmodified 3rd party files. Third party files were used > as starting points for the development of NuttX-specific applications. All > were highly modified and converted to the NuttX coding standard. See here for how to treat 3rd party works [1]. In general the changes need to be significant for the header to change. reformatting or even rewriting in another language is not a significant change as far a copyright/licensing is concerned. > We also do a less common thing that you should be aware of: We have build > scripts that download 3rd party code from the source repositories or > releases, apply patches to it, and build it into NuttX. That's fine as long as the licenses are not Category X.[2] > The 3rd party code itself is never included in a NuttX release but the > scripts that will install it are. Thanks, Justin 1. https://www.apache.org/legal/src-headers.html#3party 2 https://www.apache.org/legal/resolved.html#category-x
Re: [nuttx] Wiki Backup
I would be happy to push this forward. If there is a test space I can give it a go this evening. I’ve created a test space for you, if you need another just ask. https://cwiki.apache.org/confluence/display/NUTTXTEST There are only a few things that need to be brought in. From DocuWiki, there is only data/pages which holds the Wiki .txt files. The only issue there are the files nuttx.txt which is the landing page and navigation.txt which is the sidebar. navigation.txt WILL cause some problems. It uses a sidebar plug-in that no longer exists and can't be updated. Basically, there will need to be a new sidebar design based on navigation .txt. There are also several directories unrelated to DocuWiki that need to come along because they include documents and images referenced in DocuWiki: Images/, Documenation/, Videos/, nxwidgets_v1_19/, That is really all you need to know. Will you need FTP access to get these non-DocuWiki directories?
Re: [nuttx] Wiki Backup
Justin, Username is btashton Greg could you send me a zip with the raw wiki folder? That would simplify things for me. Thanks, Brennan On Sun, Dec 15, 2019, 1:07 PM Justin Mclean wrote: > Hi, > > I’ve given the PPMC basic permissions, if you need more ask. > > Thanks, > Justin
File headers [was Re: ICLA needed?]
Hi, > When Samsung got the NuttX files they put an Apache license header > over the BSD header, now the original BSD Header will disappear from > NuttX project files. Correct we’ll replace, where needed, the original BSD header with an ASF one. Note that the ASF has a different header for it’s projects. [1] > So, could we just remove the original BSD header > from Samsung modified files and just keep their Apache license into > those file? I don’t recommend we do that as they may of made changes or the files may of changed since they copied them. They probably also used teh 3rd party header not the ASF one. Thanks, Justin 1. https://www.apache.org/legal/src-headers.html
Re: ICLA needed?
In the nuttx/ repository, there are a total 10,626 .c and .h files with copyrights in the header (which should be all of them). Build-related files may also have copyrights but are excluded here. I hold the copyright on 8,328 of them (78%). Sony holds the copyright 401 files on (<4%) and Pinecone holds the copyright on 86 (<1%). In those count Did you exclude 3rd party files? Also, there are no unmodified 3rd party files. Third party files were used as starting points for the development of NuttX-specific applications. All were highly modified and converted to the NuttX coding standard. But we do retain the original BSD copyrights as required by the license. But it is not really 3rd party code anymore. It was adopted. We also do a less common thing that you should be aware of: We have build scripts that download 3rd party code from the source repositories or releases, apply patches to it, and build it into NuttX. The 3rd party code itself is never included in a NuttX release but the scripts that will install it are.
Re: [nuttx] Wiki Backup
Hi, I’ve given the PPMC basic permissions, if you need more ask. Thanks, Justin
Re: [nuttx] Wiki Backup
Hi, > I would be happy to push this forward. If there is a test space I can give > it a go this evening. I’ve created a test space for you, if you need another just ask. https://cwiki.apache.org/confluence/display/NUTTXTEST I’ll need your account name to give you permissions Thanks, Justin
Re: ICLA needed?
Hi, > You mean like Samsung did (and Motorola and project Ara an on and on..). Not really in the spirit of OS there, sorry that happened. > Samsung took the code from me first. I would not be taking any of their code > at all. Just their license. They may of made changes and we would need to check, but I don’t think there any need for this as the BSD license is compatible. Thanks, Justin
Re: [nuttx] Wiki Backup
Moving to the dev list. Infra have go back to use and are willing to try it, but need someone to help. Can someone here help? I am the only person that knows that Wiki well. I don't believe that there any anyone else that can help. And I would be glad to help. Greg
Re: ICLA needed?
Well it possible to use the code and both licenses are compatible. You would generally want have people be involved and donate code rather than just taking it. You mean like Samsung did (and Motorola and project Ara an on and on..). Samsung took the code from me first. I would not be taking any of their code at all. Just their license. My BSD headers and Copyrights are fully intact in the Samsung files.
Re: [nuttx] Wiki Backup
Justin, I would be happy to push this forward. If there is a test space I can give it a go this evening. --Brennan On Sun, Dec 15, 2019, 12:49 PM Justin Mclean wrote: > Hi, > > Moving to the dev list. > > Infra have go back to use and are willing to try it, but need someone to > help. Can someone here help? > > See [1] for details. > > Thanks, > Justin > > 1. https://issues.apache.org/jira/browse/INFRA-19570 > >
Re: Podling status page
Hi, > And committed a new nuttx.xml file under trunk/content/projects, but then I > was checking the svn log, and I saw a commit from you adding a nuttx.yml file > under trunk/content/podlings. Is the documentation stale and we are supposed > to track the status in the file you added? Could you please clarify? Currently you need both files, the yml one is not well documented. Thanks, Justin
Re: ICLA needed?
Hi, > But I suppose, since it is done under Samsungs legal responsibility, we could > bring any code back from Samsung? (as if I had a clue what I am talking > about). Well it possible to use the code and both licenses are compatible. You would generally want have people be involved and donate code rather than just taking it. Thanks, Justin
Re: NuttX Copyright Info.
Hi, We would need to refine that list to explode 3rd party code, what matters is which files we going to change the headers on to Apache. Thanks, Justin
Re: ICLA needed?
Perhaps it would be more efficient if you could forward my reply now. I can add more if I am granted access. Nevermind, I see that I don't have to join the list to post. Everything should be there (although I do not see my long response yet).
Re: ICLA needed?
1. https://lists.apache.org/thread.html/d58f8edd36eff155f061e84229dc035a71ea5cd7f0fa622bdd1a5dd0%40%3Clegal-discuss.apache.org%3E Some general comments on that thread: "It would be more accurate to say that Gregory Nutt *claims* copyright over the whole code. However, the facts you give — that he reviewed contributions, committed them, and slapped his own copyright notice on top — do not imply that the copyright notice is accurate." -- That has never happened. I insist that contributions of new files have the copy right notice and author on them. I have never "slapped" my on copyright on anything. "* the Foundation claims copyright on the _distribution_ rather than the individual files/contributions/commits. ... If we accept that GNutt did the same, then we're good to go. (I can't answer that statement)" -- There are copyrights ONLY on individual files. There is no copyright at all on the distributions. Modifications to files do not change the copyright by default UNLESS the commit/patch modifies the copyright. Basically copyright claims are managed entirely be the people that create and modify the code and no one else. "If there's someone else who holds a significant copyright interest — e.g., if someone contributed large amounts of code that were merged without significant alteration — then SGAs from that party would be required too." In the nuttx/ repository, there are a total 10,626 .c and .h files with copyrights in the header (which should be all of them). Build-related files may also have copyrights but are excluded here. I hold the copyright on 8,328 of them (78%). Sony holds the copyright 401 files on (<4%) and Pinecone holds the copyright on 86 (<1%). That accounts for 82% of such files. Looking at the remaining files, I do no see anyone holding large number of copyrights. Perhaps Nick Johnson who did the original math library? I doubt any there is any other copyright holder that exceeds the 1% range. The apps/ directory should be similar, but I did not look at it. "Might be worth asking Gregory Nutt if there was a NuttX contributor's agreement (expressed or implied) that assigned copyright. My employee agreement assigns copyright, for example." -- No, no contributor agreements.
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
