date:20200423

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 branch branch because we have set a rule that 
all new code must conform to the Apache 2.0 license. But there can be 
exceptions to that rule.  We can bring third party code into the 
repository too as long as it has such a compatible license.  Given that 
we have been trying unsuccessfully to get an SGA from NXP, perhaps we 
should consider this route.  We will have to do a few things:


1. We need some advice from one of our mentors (Justin?) on exactly
   what we need to do be bring this third party code into the
   repository.  I presume that everything is summarized here:
   https://www.apache.org/legal/resolved.html (but I am not very good
   at reading bureaucratic documents so nothing spoke clearly to me).
2. We need to rebase the SocketCAN branch master, and
3. Re-verify functionality of the SocketCAN branch (Peter would have to
   do this), and finally,
4. Merge the SocketCAN branch onto master.  I don't think any further
   review or checks are required (but ARE certainly welcom).  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 network sockets and a few CAN drivers.

What say you all?  Can we proceed on this and get this out of the way?  
If not, what exactly are we waiting for?

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 compatible with the Apache 2.0 license.
>
> The code is stuck on this branch branch because we have set a rule that
> all new code must conform to the Apache 2.0 license. But there can be
> exceptions to that rule.  We can bring third party code into the
> repository too as long as it has such a compatible license.  Given that
> we have been trying unsuccessfully to get an SGA from NXP, perhaps we
> should consider this route.  We will have to do a few things:
>
>  1. We need some advice from one of our mentors (Justin?) on exactly
> what we need to do be bring this third party code into the
> repository.  I presume that everything is summarized here:
> https://www.apache.org/legal/resolved.html (but I am not very good
> at reading bureaucratic documents so nothing spoke clearly to me).
>  2. We need to rebase the SocketCAN branch master, and
>  3. Re-verify functionality of the SocketCAN branch (Peter would have to
> do this), and finally,
>  4. Merge the SocketCAN branch onto master.  I don't think any further
> review or checks are required (but ARE certainly welcom).  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 network sockets and a few CAN drivers.
>
> What say you all?  Can we proceed on this and get this out of the way?
> If not, what exactly are we waiting for?

I would love it if we could merge the code soon.

I, too, would like to hear from our mentors regarding the licensing.
AFAIK, Apache projects can use BSD or similarly licensed code, with a
proper note about it in the LICENSE file, but I'd want to be sure.

Cheers,
Nathan

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 network sockets and a few CAN drivers.


Looking at the files modified, I think some review will be necessary.  
There are several files modified that are not strictly related to 
SocketCAN or s32k1xx.  This is all files modified by the changes on the 
branch:


$ git diff master..SocketCAN --name-only
arch/arm/src/s32k1xx/Kconfig
arch/arm/src/s32k1xx/Make.defs
arch/arm/src/s32k1xx/hardware/s32k1xx_flexcan.h
arch/arm/src/s32k1xx/s32k1xx_flexcan.c
arch/arm/src/s32k1xx/s32k1xx_flexcan.h
arch/arm/src/s32k1xx/s32k1xx_rtc.c
arch/arm/src/s32k1xx/s32k1xx_rtc.h
boards/arm/s32k1xx/s32k148evb/src/s32k1xx_clockconfig.c
*fs/vfs/fs_write.c*
include/netpacket/can.h
*include/nuttx/can.h*
include/nuttx/can/error.h
*include/nuttx/mm/iob.h
*include/nuttx/net/can.h
*include/nuttx/net/net.h
include/nuttx/wqueue.h
include/sys/socket.h
libs/libc/net/lib_recvmsg.c
libs/libc/net/lib_sendmsg.c
net/Kconfig
net/Makefile
net/bluetooth/bluetooth_sockif.c
*net/can/Kconfig
net/can/Make.defs
net/can/can.h
net/can/can_callback.c
net/can/can_conn.c
net/can/can_getsockopt.c
net/can/can_input.c
net/can/can_notifier.c
net/can/can_poll.c
net/can/can_recvfrom.c
net/can/can_send.c
net/can/can_setsockopt.c
net/can/can_sockif.c
*net/devif/Make.defs
net/devif/devif.h
net/devif/devif_cansend.c
net/devif/devif_pktsend.c
net/devif/devif_poll.c
net/icmp/icmp_sockif.c
net/icmpv6/icmpv6_sockif.c
net/ieee802154/ieee802154_sockif.c
net/inet/inet_sockif.c
net/local/local_sendpacket.c
net/local/local_sockif.c
net/net_initialize.c
net/netdev/netdev_register.c
net/netlink/netlink_sockif.c
net/pkt/pkt_sockif.c
net/socket/Kconfig
net/socket/Make.defs
net/socket/getsockopt.c
net/socket/net_sockif.c
net/socket/recvmsg.c
net/socket/sendmsg.c
net/socket/setsockopt.c
net/socket/socket.h*

I think that all of the files marked in read need some more detailed 
review since they effect other logic.  The few that I have studied look 
fine, but we need to be especially careful with modifications to files 
that can have side-effects.  If the JPPMC agrees to the merge, then I 
will run all files through nxstyle again before the merge.

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.
AFAIK, Apache projects can use BSD or similarly licensed code, with a
proper note about it in the LICENSE file, but I'd want to be sure.


In lack of other direction, I propose that we follow what the Mynewt 
project has done:  https://github.com/apache/mynewt-core


That is an IoT RTOS and, as a project, has similar properties as the 
NuttX project.  Also, Justin Mclean is the chair of the Mynewt project 
so I think we can be assure that it follows all of the rules.


There is a LOT of third party code in the Mynewt repositories. As 
examples:  crypto/mbedtls (Apache from ARM), crypto/tinycrypt (BSD from 
Intel), encoding/json (BSD), and probably more.  Many non-Apache files 
are listed in the top-level LICENSE file

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

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. Mynewt 
made a lot of effort to get permission to use code and in some cases change 
licensing with 3rd parties.

Thanks,
Justin

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.  When I last talked to folks at NXP, they said that 
they were still talking to legal, but no progress had been made.

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. Mynewt 
made a lot of effort to get permission to use code and in some cases change 
licensing with 3rd parties.


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?

Re: What should we we do with SocketCAN

2020-04-23 Thread Alan Carvalho de Assis

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 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.
> Mynewt made a lot of effort to get permission to use code and in some cases
> change licensing with 3rd parties.
>
> Thanks,
> Justin

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 say) IMO if that is the case we 
should remove the code.

Thanks,
Justin

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 
is needed. A CCLA would be a show of good faith or something else official from 
them to say there are no issues with using their code.

Thanks,
Justin

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) IMO if that is the case we 
should remove the code.


Is that the official Apache position?  Sometimes is it is difficult to 
separate your opinion (which you have a right to) from the official 
requirements of the ASF.  You opinion should be taken into account as 
with all other interested parties, but we all must comply with the ASF 
requirements.


It this discussion, I think it depends on which rights you are referring 
to.  I am speaking only of the legal rights as state in the license of 
the file.  That is the part that legal people are hesitant to change.  
The licenses do permit use by use and the contributors do want us to 
exercise those rights and use the software in NuttX.  So I think we are 
mixing issues here.


The code permits its re-use, the authors want us to incorporate it, the 
ASF third party web pages I have seen say it is compatible, what else 
will be needed to prove that they give us the rights to use the code 
(which we already have).  The are not going to do an SGA in my lifetime, 
nor will Xiaomi, nor will Sony, nor with PX4.  That just isn't going to 
happy.  But that does not mean that they are not encouraging us to use 
the code.


This just gets less clear to me all of the time.  What, as a minimum, do 
we have to do to satisfy the requirements of the ASF? Isn't everything 
here:  https://www.apache.org/legal/resolved.html


Are we adding ad hoc requirements on top of the ASF requirements?

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 only of the legal rights as state in the license of the file.

ASF policy goes beyond (for good reasons) what is just legally possible.

Thanks,
Justin

STM32H7 FDCAN driver

2020-04-23 Thread John Rippetoe


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 
only been testing by using the CAN example program running in loopback 
mode since I do not currently have any external devices to test with.


The FDCAN hardware in the H7 is a pretty significant departure from the 
F7 and earlier, so there is some additional functionality that the 
current upper-level CAN driver isn't really setup to support. I wanted 
to bring the community in on my efforts so we could discuss those things 
and decide whether they are worth pursuing. I personally have zero prior 
experience with CAN, so I am not sure what hardware features are 
typically utilized by most developers here.


The biggest difference that sets the H7 FDCAN apart from its 
predecessors is the storage of messages. Unlike previous hardware that 
made use of a fixed number of mailboxes for sending/receiving messages, 
the H7 FDCAN integrates a 10kb segment of memory called the Message RAM 
that is dedicated to the peripheral. All messages, both transmitted and 
received, and filters are stored here. But more interestingly, the RAM 
is dynamically configured by the user during the initialization process 
based on their needs and can be split up into a variety of sections. I 
don't want to get into a lot of detail here since I am likely telling 
people what they already know, so interested parties should look at [1] 
for a great summary of what the hardware can do. What I would like to 
discuss right now is what features we want to use and some 
implementation ideas for them. Since the upper-level driver places 
messages into FIFOs, it is easy to make use of the Rx and Tx FIFOs in 
hardware. The filters will also be necessary for the driver to function. 
Right now, I have created kconfig options for configuring the sections 
in RAM. That allows to user to specify what sections they want, how many 
messages they want to store in each section, and how big the messages 
are expected to be.


So what works right now? In short, the driver currently replicates the 
functionality of the F7 driver. Here is a bullet list


 * Hardware initialization
 * Bit timing
 * Message RAM setup for filters and FIFOs, configurable via kconfig
 * Rx/Tx FIFOs with appropriate interrupts
 * IOCTL calls implemented by F7 driver (no add/del filters)
 * Txready/Txdone functions
 * Functions to send/receive messages within hardware
 * Tx/Rx interrupt enable/disable


What work needs to be done?

 * Settle on what features to implement and a way to represent the
   message RAM layout for efficient use by the driver
 * Add support for RTR messages
 * Add support for FD mode
 * Add config option to enable/disable FIFO overwrite (default setup is
   to block when full)
 * Add support for bitrate switching?
 * LOTS of testing
 * nxstyle checks
 * licensing since two files are derived from the F7 code that has
   non-ASF licenses.


For now, I think the best path forward is to match the feature set of 
existing CAN drivers. That will allow us to get the basics working and 
well tested before moving onto anything that might require us to modify 
the upper-level driver to add more advanced features such as bitrate 
switching. So that means only using the hardware FIFOs for now. I think 
we should allow the user to configure the message RAM via kconfig 
options for maximum flexibility in the future. Even if we only add 
options for the filter and FIFO sections right now, adding in additional 
features later would be much easier with the infrastructure in place.  
It also lets the user specify exactly what they want, removing the need 
for the driver to hardcode potentially stupid assumptions. For 
filtering, I have currently enabled a single bitmask filter to accept 
all incoming messages. Implementing the add/del filter IOCTL calls 
should be trivial, but I have some concerns there as well.


Please feel free to take a look at the code on my H7CAN branch 
 - I am 
prepared for a good old-fashioned code mocking 
. The code 
follows the same structure as the F7 and earlier drivers and is well 
documented I think.  It is also based off my work in progress port of 
the STM32H753XI evaluation board, so you will see a few commits 
sprinkled in that are specific to my board.


Regards,

John Rippetoe


CONFIDENTIALITY NOTICE: This communication may contain private, confidential 
and privileged material for the sole use of the intended recipient. If you are 
not the intended recipient, please delete this e-mail and any attachments 
permanently.

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 that I'm working on architectural
support in NuttX for the STM32G474 family, which also has FDCAN.
In fact, yesterday, I was working on the pinmap for several
peripherals, including the FDCAN. My work is in my fork on GitHub, in
https://github.com/hartmannathan/incubator-nuttx in the branch
stm32g474. This being a recent addition to STM32's family line,
perhaps the FDCAN peripherals share some common lineage and maybe we
could split some of the work to support it. I'm not ready yet, because
first need to get minimal support up and running, to initialize the
sysclk and boot up NuttX on my board, but I thought it be helpful to
mention.

Cheers,
Nathan

Re: STM32H7 FDCAN driver

2020-04-23 Thread John Rippetoe

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 
the same. The main difference appears to be in the number of CAN cores 
(3 in the G4 vs 2 in the H7) and the amount of message RAM (1Kb per core 
in the G4 vs 10Kb shared between the 2 cores in the H7). It also appears 
that there is no Time Triggered CAN functionality in the G4. So it seems 
like it should be pretty easy for us to collaborate.


- John


On 4/23/20 4:29 PM, Nathan Hartman wrote:

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 that I'm working on architectural
support in NuttX for the STM32G474 family, which also has FDCAN.
In fact, yesterday, I was working on the pinmap for several
peripherals, including the FDCAN. My work is in my fork on GitHub, in
https://github.com/hartmannathan/incubator-nuttx in the branch
stm32g474. This being a recent addition to STM32's family line,
perhaps the FDCAN peripherals share some common lineage and maybe we
could split some of the work to support it. I'm not ready yet, because
first need to get minimal support up and running, to initialize the
sysclk and boot up NuttX on my board, but I thought it be helpful to
mention.

Cheers,
Nathan

CONFIDENTIALITY NOTICE: This communication may contain private, confidential 
and privileged material for the sole use of the intended recipient. If you are 
not the intended recipient, please delete this e-mail and any attachments 
permanently.

Re: STM32H7 FDCAN driver

2020-04-23 Thread John Rippetoe

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 PM, John Rippetoe wrote:

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 only been testing by using the CAN example program running in
loopback mode since I do not currently have any external devices to
test with.

The FDCAN hardware in the H7 is a pretty significant departure from
the F7 and earlier, so there is some additional functionality that the
current upper-level CAN driver isn't really setup to support. I wanted
to bring the community in on my efforts so we could discuss those
things and decide whether they are worth pursuing. I personally have
zero prior experience with CAN, so I am not sure what hardware
features are typically utilized by most developers here.

The biggest difference that sets the H7 FDCAN apart from its
predecessors is the storage of messages. Unlike previous hardware that
made use of a fixed number of mailboxes for sending/receiving
messages, the H7 FDCAN integrates a 10kb segment of memory called the
Message RAM that is dedicated to the peripheral. All messages, both
transmitted and received, and filters are stored here. But more
interestingly, the RAM is dynamically configured by the user during
the initialization process based on their needs and can be split up
into a variety of sections. I don't want to get into a lot of detail
here since I am likely telling people what they already know, so
interested parties should look at [1] for a great summary of what the
hardware can do. What I would like to discuss right now is what
features we want to use and some implementation ideas for them. Since
the upper-level driver places messages into FIFOs, it is easy to make
use of the Rx and Tx FIFOs in hardware. The filters will also be
necessary for the driver to function. Right now, I have created
kconfig options for configuring the sections in RAM. That allows to
user to specify what sections they want, how many messages they want
to store in each section, and how big the messages are expected to be.

So what works right now? In short, the driver currently replicates the
functionality of the F7 driver. Here is a bullet list

* Hardware initialization
* Bit timing
* Message RAM setup for filters and FIFOs, configurable via kconfig
* Rx/Tx FIFOs with appropriate interrupts
* IOCTL calls implemented by F7 driver (no add/del filters)
* Txready/Txdone functions
* Functions to send/receive messages within hardware
* Tx/Rx interrupt enable/disable

What work needs to be done?

* Settle on what features to implement and a way to represent the
message RAM layout for efficient use by the driver
* Add support for RTR messages
* Add support for FD mode
* Add config option to enable/disable FIFO overwrite (default setup
is to block when full)
* Add support for bitrate switching?
* LOTS of testing
* nxstyle checks
* licensing since two files are derived from the F7 code that has
non-ASF licenses.

For now, I think the best path forward is to match the feature set of
existing CAN drivers. That will allow us to get the basics working and
well tested before moving onto anything that might require us to
modify the upper-level driver to add more advanced features such as
bitrate switching. So that means only using the hardware FIFOs for
now. I think we should allow the user to configure the message RAM via
kconfig options for maximum flexibility in the future. Even if we only
add options for the filter and FIFO sections right now, adding in
additional features later would be much easier with the infrastructure
in place. It also lets the user specify exactly what they want,
removing the need for the driver to hardcode potentially stupid
assumptions. For filtering, I have currently enabled a single bitmask
filter to accept all incoming messages. Implementing the add/del
filter IOCTL calls should be trivial, but I have some concerns there
as well.

Please feel free to take a look at the code on my H7CAN branch
- I am
prepared for a good old-fashioned code mocking
. The code
follows the same structure as the F7 and earlier drivers and is well
documented I think. It is also based off my work in progress port of
the STM32H753XI evaluation board, so you will see a few commits
sprinkled in that are specific to my board.

Regards,

John Rippetoe

CONFIDEN

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 question. Legally nothing is needed and ASF policy wise 
> nothing is needed. A CCLA would be a show of good faith or something else 
> official from them to say there are no issues with using their code.

In that case, since as Greg has said, both VW and NXP are enthusiastic
about getting their code into NuttX, then could we invite them to join
this dev@ list and participate in this discussion?

Nathan

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 external dependancy.
4. There's no code we are using that could be considered a hostile fork or has 
been taken without a communities permission.

If you need examples of what other projects have done. Look at what Mynewt did, 
they got several 3rd parties to change licenses and/or donate code. Look at 
Dubbo who tracked down all contributors (even those who made trivial changes) 
and got them to sign ICLAs. [2]

I would suggest that they start and ask for SGAs from major contributors and if 
the answer comes back no then move on to sorting the ICLAs where that is 
possible. I know the ICLAs was looked into a while back for some parts of the 
code, but seems to have stalled a little? [1]

Back to this code in question. I’m a little confused as to the situation here.

Looking at the file list given before as most of the code is copyright Gregory 
Nutt and has the NuttX BSD header on it. I can see two files copyright  Adam 
Dunkels that probably should revert to the original headers (depending on how 
much code has changed), I see one file from Freescale/NXP in a similar 
situation. There is only one file from the  Volkswagen Group Electronic 
Research.

Who actually made the changes here and do we have ICLAs from them?

Thanks,
Justin

1. https://cwiki.apache.org/confluence/display/NUTTX/License+Clearing
2. https://github.com/apache/dubbo/wiki/CLA-signing-status

Re: Start of the NuttX 9.0 release cycle

2020-04-23 Thread Abdelatif Guettouche

> 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:
>
> On Wed, Apr 22, 2020, 6:11 PM Abdelatif Guettouche <
> abdelatif.guettou...@gmail.com> wrote:
>
> > > Correct. I’ve created them for you.
> >
> > Thanks, Justin.
> > Brennan, is your script wired to those locations?
> >
>
> 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.
>
> Let me send a PR that will cause the CI to perform a build on tag. It's the
> non controversial part of the packaging PR. This way we know the two tags
> pass all the tests.
>
>
> > There is a new PR that fixes a recent bug [1], that bug exists also in
> > the release branch, it looks like a candidate for backporting.
> > I'll create a PR for that, if you all agree, please merge.
> >
> > 1. https://github.com/apache/incubator-nuttx/pull/843
>
>
> Looks like something we should pull in.  I think there might be something
> that needs to be backported related to Apps. The build is failing.
>
> --Brennan

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 
changes here might be too small for a SGA.

Thanks,
Justin

Re: Start of the NuttX 9.0 release cycle

2020-04-23 Thread Brennan Ashton

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 merged, can you
> move forward with this?
>

Happy to do it this evening (few hours from now).

I would tag what is currently the tip of incubating-nuttx and
incubating-nuttx-apps on the releases/9.0 both as nuttx-9.0.0-RC0

Does this sound like a good plan?

--Brennan

>

Re: Start of the NuttX 9.0 release cycle

2020-04-23 Thread Abdelatif Guettouche

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 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?
> >
>
> Happy to do it this evening (few hours from now).
>
> I would tag what is currently the tip of incubating-nuttx and
> incubating-nuttx-apps on the releases/9.0 both as nuttx-9.0.0-RC0
>
> Does this sound like a good plan?
>
> --Brennan
>
> >

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 it has an active community elsewhere and
> can be used as an external dependancy.
> 4. There's no code we are using that could be considered a hostile fork or
> has been taken without a communities permission.
>
> If you need examples of what other projects have done. Look at what Mynewt
> did, they got several 3rd parties to change licenses and/or donate code.
> Look at Dubbo who tracked down all contributors (even those who made
> trivial changes) and got them to sign ICLAs. [2]
>
> I would suggest that they start and ask for SGAs from major contributors
> and if the answer comes back no then move on to sorting the ICLAs where
> that is possible. I know the ICLAs was looked into a while back for some
> parts of the code, but seems to have stalled a little? [1]


This is very helpful! Thank you!

Would it be okay with you if we make a wiki page about what code can get
into NuttX, and use (part of) the above there? (In particular items 1
through 4).

Cheers
Nathan

Re: Start of the NuttX 9.0 release cycle