Re: [nuttx] Fwd: [ANNOUNCEMENT] Call for Validation of Apache NuttX 9.0.0 (incubating) RC0

> > > What do you mean by validation? The way most project do this is with a > formal [VOTE] thread on the release candidate or is this just checking that > everyone is OK before calling a vote? > Since it is our first release I figured it would be worth giving people more time than the usual voti

Build failed in Jenkins: NuttX-Nightly-Build #105

See Changes: -- [...truncated 4.52 MB...] sched/pthread_setaffinity.d sched/pthread_setschedparam.d sched/pthread_setschedprio.d sched/pthread_setspeci

[ANNOUNCEMENT] Call for Validation of Apache NuttX 9.0.0 (incubating) RC0

Some good news! After many months of hard work by our users, code contributors, and a lot of patience assistance from our Apache Mentors, Apache NuttX (Incubating) 9.0.0-RC0 has been staged under [1]. While there were a lot of people who put serious work into the release I would like to personall

Re: Start of the NuttX 9.0 release cycle

On Thu, Apr 23, 2020 at 8:02 PM Brennan Ashton wrote: > > On Thu, Apr 23, 2020, 4:52 PM Abdelatif Guettouche < > abdelatif.guettou...@gmail.com> wrote: > > > > Not much to it but yeah. Do you want me to push a RC0 to staging tonight, > > > we just need to tag the apps and os and kick off a build t

Re: What should we we do with SocketCAN

On Thu, Apr 23, 2020 at 7:39 PM Justin Mclean wrote: > Hi, > > Here would would be the ideal from an ASF point of view: > 1. All large pieces of 3rd party code is donated to the ASF via SGAs > 2. If not, anyone who worked on large contributors have a signed ICLA. > 3. Remove the 3rd party code if

Re: Start of the NuttX 9.0 release cycle

Awesome! Thanks! Meanwhile, I'm doing some tests with the branch locally. All seem normal. On Fri, Apr 24, 2020 at 1:02 AM Brennan Ashton wrote: > > On Thu, Apr 23, 2020, 4:52 PM Abdelatif Guettouche < > abdelatif.guettou...@gmail.com> wrote: > > > > Not much to it but yeah. Do you want me to pu

Re: Start of the NuttX 9.0 release cycle

On Thu, Apr 23, 2020, 4:52 PM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > > Not much to it but yeah. Do you want me to push a RC0 to staging tonight, > > we just need to tag the apps and os and kick off a build the passes. > > The PRs we've been talking about in Github are now

Re: What should we we do with SocketCAN

Hi , comparing the changes between the branches and looking at the authors I only see 3: Gregory Nutt Jari van Ewijk Peter van der Perk One solution would be to get Jari and Peter to sign ICLA (I see none on file) and get a CCLA or SGA from VW (who I assume they work for). The amount of change

Re: Start of the NuttX 9.0 release cycle

> Not much to it but yeah. Do you want me to push a RC0 to staging tonight, > we just need to tag the apps and os and kick off a build the passes. The PRs we've been talking about in Github are now merged, can you move forward with this? On Thu, Apr 23, 2020 at 2:23 AM Brennan Ashton wrote: > >

Re: What should we we do with SocketCAN

Hi, Here would would be the ideal from an ASF point of view: 1. All large pieces of 3rd party code is donated to the ASF via SGAs 2. If not, anyone who worked on large contributors have a signed ICLA. 3. Remove the 3rd party code if it has an active community elsewhere and can be used as an exter

Re: What should we we do with SocketCAN

On Thu, Apr 23, 2020 at 10:43 AM Justin Mclean wrote: > > I know that both VW and NXP is okay with incoporating into NuttX. In fact, > > they are enthusiastic about it. What kind of documentation would we need > > just to get permission without changing the licensing? > > An interesting questi

Re: STM32H7 FDCAN driver

I just realized that the reference I made to an external document in my first email didn't actually get linked too. For those interested, see below. [1] https://www.st.com/resource/en/application_note/dm00625700-fdcan-peripheral-on-stm32-devices-stmicroelectronics.pdf - John On 4/23/20 3:54

Re: STM32H7 FDCAN driver

Thanks for letting me know! I was actually following the discussion on whether to include the G4 in the stm32 folder, so I knew it was being worked on. I took a quick look at the G4 reference manual and it shows that they share identical FDCAN core releases, so the basic stuff should all be t

Re: STM32H7 FDCAN driver

On Thu, Apr 23, 2020 at 3:54 PM John Rippetoe wrote: > I have been working on adding support for the FDCAN peripheral in the > STM32H7 and have a basic driver working. It's a bit of a hack in some I haven't yet read your whole email. I will revisit it soon. But in the meantime I wanted to mention

STM32H7 FDCAN driver

Hello All, I have been working on adding support for the FDCAN peripheral in the STM32H7 and have a basic driver working. It's a bit of a hack in some places right now, but it follows the same basic structure as the F7 driver, which was used as a template to start. I should note that I have o

Re: What should we we do with SocketCAN

HI, > Is that the official Apache position? Yes ASF policy is in line with that. If it “offical” is a matter of interpretation but as VP Incubator and an ASF board member I would consider it so. > It this discussion, I think it depends on which rights you are referring to. > I am speaking on

Re: What should we we do with SocketCAN

From my understanding, it is just the slow wheels of corporate legal departments. In my experience, legal departments just see no win to giving up rights. If they don’t want to give the rights to us to use it, do we actually have the rights to use it? (Despite what the license may say) IM

Re: What should we we do with SocketCAN

Hi, > I know that both VW and NXP is okay with incoporating into NuttX. In fact, > they are enthusiastic about it. What kind of documentation would we need > just to get permission without changing the licensing? An interesting question. Legally nothing is needed and ASF policy wise nothing

Re: What should we we do with SocketCAN

Hi, > From my understanding, it is just the slow wheels of corporate legal > departments. In my experience, legal departments just see no win to giving > up rights. If they don’t want to give the rights to us to use it, do we actually have the rights to use it? (Despite what the license may

Re: What should we we do with SocketCAN

Unfortunately it is not always easy, many projects doesn't like to re-license their code. What do you suggest in these cases? What to do if NXP doesn't accept to assign the SGA? On 4/23/20, Justin Mclean wrote: > Hi, > >> There is a LOT of third party code in the Mynewt repositories. > > Having

Re: What should we we do with SocketCAN

There is a LOT of third party code in the Mynewt repositories. Having 3rd party code that is under a compatible license is OK, but the ASF likes to go a step further and know that the owner is OK with this. The ASF doesn’t take code without permission or make hostile forks of projects. Mynew

Re: What should we we do with SocketCAN

Given that we have been trying unsuccessfully to get an SGA from NXP This I think in the issue why are they not willing to do this? From my understanding, it is just the slow wheels of corporate legal departments.  In my experience, legal departments just see no win to giving up rights.  W

Re: What should we we do with SocketCAN

Hi, > There is a LOT of third party code in the Mynewt repositories. Having 3rd party code that is under a compatible license is OK, but the ASF likes to go a step further and know that the owner is OK with this. The ASF doesn’t take code without permission or make hostile forks of projects. M

Re: What should we we do with SocketCAN

Hi, > Given that we have been trying unsuccessfully to get an SGA from NXP This I think in the issue why are they not willing to do this? Thanks, Justin

Re: What should we we do with SocketCAN

I would love it if we could merge the code soon. It does have a limited shelf life, if we don't get it in place to it will be a waste of a real effort and probably the most major contribution every made to Apache NuttX. I, too, would like to hear from our mentors regarding the licensing. AFA

Re: What should we we do with SocketCAN

Merge the SocketCAN branch onto master.  I don't think any further review or checks are required (but ARE certainly welcome).  All of the PRs used to create the SocketCAN branch were previously reviewed and the merge is very low risk since it should, in principle, effect only the SocketCAN ne

Re: What should we we do with SocketCAN

On Thu, Apr 23, 2020 at 9:13 AM Gregory Nutt wrote: > > As most of you know, there is a branch called SocketCAN in the > incubator_nuttx repository. This branch holds a port of port of VW's > socket CAN plus NXP copyrighted files. All are BSD licensed (the VW > code is dual licensed) and compati

What should we we do with SocketCAN

As most of you know, there is a branch called SocketCAN in the incubator_nuttx repository.  This branch holds a port of port of VW's socket CAN plus NXP copyrighted files.  All are BSD licensed (the VW code is dual licensed) and compatible with the Apache 2.0 license. The code is stuck on this