Re: Podling Nuttx Report Reminder - April 2020

[Abdelatif Guettouche]

Do we have to report?
We reported every month for the last 3 months.
My understanding is that new podlings report monthly for the first 3 months
then quarterly after that.

On Fri, Mar 20, 2020, 04:18  wrote:

> Dear podling,
>
> This email was sent by an automated system on behalf of the Apache
> Incubator PMC. It is an initial reminder to give you plenty of time to
> prepare your quarterly board report.
>
> The board meeting is scheduled for Wed, 15 April 2020, 10:30 am PDT.
> The report for your podling will form a part of the Incubator PMC
> report. The Incubator PMC requires your report to be submitted 2 weeks
> before the board meeting, to allow sufficient time for review and
> submission (Wed, April 01).
>
> Please submit your report with sufficient time to allow the Incubator
> PMC, and subsequently board members to review and digest. Again, the
> very latest you should submit your report is 2 weeks prior to the board
> meeting.
>
> Candidate names should not be made public before people are actually
> elected, so please do not include the names of potential committers or
> PPMC members in your report.
>
> Thanks,
>
> The Apache Incubator PMC
>
> Submitting your Report
>
> --
>
> Your report should contain the following:
>
> *   Your project name
> *   A brief description of your project, which assumes no knowledge of
> the project or necessarily of its field
> *   A list of the three most important issues to address in the move
> towards graduation.
> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> aware of
> *   How has the community developed since the last report
> *   How has the project developed since the last report.
> *   How does the podling rate their own maturity.
>
> This should be appended to the Incubator Wiki page at:
>
> https://cwiki.apache.org/confluence/display/INCUBATOR/April2020
>
> Note: This is manually populated. You may need to wait a little before
> this page is created from a template.
>
> Note: The format of the report has changed to use markdown.
>
> Mentors
> ---
>
> Mentors should review reports for their project(s) and sign them off on
> the Incubator wiki page. Signing off reports shows that you are
> following the project - projects that are not signed may raise alarms
> for the Incubator PMC.
>
> Incubator PMC
>

Re: Podling Nuttx Report Reminder - April 2020

[Justin Mclean]

Hi,

> My understanding is that new podlings report monthly for the first 3 months
> then quarterly after that.

That’s correct it looks like the group attribute may of been set incorrectly in 
podlings.xml I’ll double check and fix it, but given this podlings lack of 
progress I think it might be good for it to report again this month.

Thanks,
Justin

Re: Podling Nuttx Report Reminder - April 2020

[Abdelatif Guettouche]

>
> but given this podlings lack of progress I think it might be good for it
> to report again this month.

Will this help us make progress?
The report would be similar to the old one.
We've been more or less repeating the same thing for the past two reports.
Technically the project is making progress, we have daily contributions,
but I don't think this is enough for a board report.

Some of the other project management tasks are somewhat trailing behind. We
may need some time to get everything in track.


On Fri, Mar 20, 2020 at 10:43 AM Justin Mclean 
wrote:

> Hi,
>
> > My understanding is that new podlings report monthly for the first 3
> months
> > then quarterly after that.
>
> That’s correct it looks like the group attribute may of been set
> incorrectly in podlings.xml I’ll double check and fix it, but given this
> podlings lack of progress I think it might be good for it to report again
> this month.
>
> Thanks,
> Justin

Re: Podling Nuttx Report Reminder - April 2020

[Justin Mclean]

Hi,

> Will this help us make progress?

If you don’t want to report then that’s up to you.

> We've been more or less repeating the same thing for the past two reports.

Which is a concern.

> Technically the project is making progress

Which the ASF is not so concerned about, what you need to show and report on is 
how the community grows or is encouraged to grow.

>  We may need some time to get everything in track.

IMO you have had  time to do this, Some projects are slow to start but I think 
this project IMO is focusing on the wrong things. If the project continues down 
this track it is on I will have no choice but to resign as a mentor.

Thanks,
Justin

PR and issue Templates

[David Sidrane]

Hi,



We spend a lot of time on PRs repeating ourselves on format, license.



Giving directed links and examples will not challenge contributors with
having to ferret this out on their own.



@mentors Do we have the ability to add a Git hub PR and Issue template?



David







*From:* Abdelatif Guettouche [mailto:notificati...@github.com]
*Sent:* Friday, March 20, 2020 4:42 AM
*To:* apache/incubator-nuttx
*Cc:* David Sidrane; Mention
*Subject:* Re: [apache/incubator-nuttx] Support for Litex VexRiscV (#595)



@aenrbs New files need to have an Apache license. Kconfig, README and auto
generated files like defconfig don't need a license.
Note that the license holder in all of this PRs files is Gregory Nutt.
Gregory Nutt has already submitted an ICLA and gave his approval to change
his license header.

@davids5  As of now, we don't. Some has adopted
their own templates when submitting PRs.
We may want to add Github's templates for PRs/Issues. Maybe we bring this
to the dev list for a discussion on what should be there?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
,
or unsubscribe

.

Re: problem with nxsig_timeout (sig_timedwait.c)

[Gregory Nutt]

Looking at the declarations of nxsig_timeout and wdentry_t:

static void nxsig_timeout(int argc, wdparm_t itcb)
typedef CODE void (*wdentry_t)(int argc, uint32_t arg1, ...);


A sidenote:  You must be looking at a very old code base.  The current 
type for wdentry_t is:


   133 typedef CODE void (*wdentry_t)(int argc, wdparm_t arg1, ...);

That was changed in 2015:

   commit 3adcae8ffbf247f1038bbb3b8281ea811799031e
   Author: Gregory Nutt 
   Date:   Mon May 18 08:53:42 2015 -0600

    Update the type passed to watchdog timer handlers. Using
   uint32_t is a problem for 64-bit machines.

   ...

 /* This is the form of the function that is called when the
  * watchdog function expires.  Up to four parameters may be passed.
  */

   -typedef CODE void (*wdentry_t)(int argc, uint32_t arg1, ...);
   +typedef CODE void (*wdentry_t)(int argc, wdparm_t arg1, ...);

But it is only the variable number of arguments vs. the fixed number of 
arguments that concerns you.


Greg

Re: Apache 2.0 License headers in source files

[Nathan Hartman]

On Sat, Mar 7, 2020 at 9:45 PM Brennan Ashton  wrote:
> Adam if you look back I have a hosted instance of it running for the
> project, no sense in duplicating the work. I'm happy to provide you an
> account. The nice thing about using this is that the reports can be shared
> publicly and we can use the proper flow of working through the identified
> license and copyrights and then marking them as resolved.

Hi all,

I'd like to nudge (or pehaps push and shove) Apache NuttX toward
making our first release as an Apache podling. Along those lines I'd
like to revive this conversation...

Where are we in terms of Fossology, Rat, and tracking down copyrights,
in the move toward applying Apache 2.0 headers to our source files?
I.e., how much has been done, what remains to be done, what specific
things do we need help with, and can/should we make a "Call To Action"
to our community to put more emphasis on getting this done?

On a related note, would it be appropriate to open a "Do Not Merge" PR
on GitHub, for the purposes of applying the header to each file as it
is cleared, and also as a central location for all interested persons
to collaborate on this (admittedly large) task?

Or would it be more appropriate to open a PR for each file (or set of
a few files) as they are cleared? Perhaps files that are cleared
should immediately shift to Apache header, and files that prove to be
more problematic should immediately be marked with some code that we
can easily `grep' for in their header, so that it will be easier to
keep track of what they are, and of who (people and/or companies) we
need to reach out to for permission to change the headers?

Finally (this is more a question for our mentors), assuming we have a
proper DISCLAIMER, is there any reason for this licensing work to be a
release blocker for our first Apache release?

Thanks,
Nathan

Re: Apache 2.0 License headers in source files

[Brennan Ashton]

On Fri, Mar 20, 2020, 7:29 AM Nathan Hartman 
wrote:

> On Sat, Mar 7, 2020 at 9:45 PM Brennan Ashton 
> wrote:
> > Adam if you look back I have a hosted instance of it running for the
> > project, no sense in duplicating the work. I'm happy to provide you an
> > account. The nice thing about using this is that the reports can be
> shared
> > publicly and we can use the proper flow of working through the identified
> > license and copyrights and then marking them as resolved.
>
> Hi all,
>
> I'd like to nudge (or pehaps push and shove) Apache NuttX toward
> making our first release as an Apache podling. Along those lines I'd
> like to revive this conversation...
>


Personally I got a little turned away on this when we had the conversation
to work on this and start a path forward and immediately PRs got merged
including one I commented on that violated the plan. This is a difficult
task and we should not be making it harder on ourselves.

We CANNOT just go and update the headers on files unless Greg is the only
author and all other non trivial contributors have signed some form of
CLA.  I would feel very uncomfortable signing off on a release without a
review of these files that got changed, disclaimer or not.

--Brennan

>

Re: Apache 2.0 License headers in source files

[Gregory Nutt]

I'd like to nudge (or pehaps push and shove) Apache NuttX toward
making our first release as an Apache podling.
The last release, 8.2, was from mid-November 2019.  Releases had been 
been made religiously every two months for years up until 8.2. We are 
approaching 6 months with no releases.  I am sure that the community is 
well aware of this.

Re: Build errors with inline functions

[Nathan Hartman]

On Thu, Mar 19, 2020 at 6:38 PM Gregory Nutt  wrote:

>
> > More likely is the fact that inlining is disabled at -O0 and now the
> > functions really are implemented as static functions and generate
> > static functions.  Now you really do have unreferenced static
> > functions.  Try removing the static storage class from the inline
> > prototypes.
>
> What would work best for header files is to declare inline functions as
> extern.  Then provide a C file with the inline function definitions.
> this is preferable because it works in all cases:  It works when
> inlining is not enabled and it works with C89 compilers.  This is
> recommended: https://gcc.gnu.org/onlinedocs/gcc/Inline.html


>From that page: "This combination of inline and extern has almost the
effect of a macro. The way to use it is to put a function definition in a
header file with these keywords, and put another copy of the definition
(lacking inline and extern) in a library file. The definition in the header
file causes most calls to the function to be inlined. If any uses of the
function remain, they refer to the single copy in the library."

To use the correct technical terminology, that *sucks*, because it means
that we will have two copies of functions, which leads to a maintenance
nightmare.


>  static inline in header files is never recommended:

https://groups.google.com/forum/#!topic/mozilla.dev.platform/Ulw9HoZbSyQ


That refers to code written in C++, not C. Later in the discussion, the OP
writes: "You example is C. I had C++ in mind, as our codebase is
predominantly C++. I should have made that clear. My point is that we have
lots of file-scope static inlines in C++ headers. "

C++ is sometimes said to be a "superset of C" but that isn't really true.
Things are different in subtle ways that often lead to headaches, like this
one.

In C, if placing a function in a header, "static inline" is needed to avoid
a "multiple definitions" problem, but means that if the compiler decides
*not* to inline the function, and if the function is used from multiple C
modules, then some code bloat results because you could end up with
multiple copies of the object code in your executable. But I consider this
to be a negligible problem because you should not make functions inline
unless they're really short and simple anyway.

There is another option: Macros instead of inline functions. Those come
with advantages and disadvantages as well, but if written as follows:

#define my_macro(x,y) do { blah blah blah } while (0)

or

#define my_multiline_macro(x,y) do { \
blah \
blah \
blah \
} while (0)

then its being a macro becomes transparent to all callers. See
https://stackoverflow.com/questions/257418/do-while-0-what-is-it-good-for.

I've seen entire libraries implemented as C headers full of macros. Such as:

Here's an example:

https://github.com/silentbicycle/greatest/blob/master/greatest.h

By the way, that's a very, very useful automated testing library, all
self-contained in one header file.

Cheers,
Nathan

Re: Apache 2.0 License headers in source files

[Xiang Xiao]

On Fri, Mar 20, 2020 at 10:37 PM Brennan Ashton
 wrote:
>
> On Fri, Mar 20, 2020, 7:29 AM Nathan Hartman 
> wrote:
>
> > On Sat, Mar 7, 2020 at 9:45 PM Brennan Ashton 
> > wrote:
> > > Adam if you look back I have a hosted instance of it running for the
> > > project, no sense in duplicating the work. I'm happy to provide you an
> > > account. The nice thing about using this is that the reports can be
> > shared
> > > publicly and we can use the proper flow of working through the identified
> > > license and copyrights and then marking them as resolved.
> >
> > Hi all,
> >
> > I'd like to nudge (or pehaps push and shove) Apache NuttX toward
> > making our first release as an Apache podling. Along those lines I'd
> > like to revive this conversation...
> >
>
>
> Personally I got a little turned away on this when we had the conversation
> to work on this and start a path forward and immediately PRs got merged
> including one I commented on that violated the plan. This is a difficult
> task and we should not be making it harder on ourselves.
>
> We CANNOT just go and update the headers on files unless Greg is the only
> author and all other non trivial contributors have signed some form of
> CLA.  I would feel very uncomfortable signing off on a release without a
> review of these files that got changed, disclaimer or not.
>

Is it enough that if the following criteria meet:
1.The file is BSD license
2.The file is created by Greg
3.The file state that Greg is one and only one owner
Then we can convert it's license to Apache.
It's almost impossible to finish the license job if we need review the
history line by line to identify all contributors who make the non
trival change.

> --Brennan
>
> >

Re: Apache 2.0 License headers in source files

[Xiang Xiao]

On Fri, Mar 20, 2020 at 10:46 PM Gregory Nutt  wrote:
>
>
> > I'd like to nudge (or pehaps push and shove) Apache NuttX toward
> > making our first release as an Apache podling.
> The last release, 8.2, was from mid-November 2019.  Releases had been
> been made religiously every two months for years up until 8.2. We are
> approaching 6 months with no releases.  I am sure that the community is
> well aware of this.
>

Since the result from the nightly and precheck build looks good and
stable, I think it's time to schedule the first Apache release once
the license issue(at least all files owned by Greg) get resolved.

Re: Apache 2.0 License headers in source files

[Gregory Nutt]

We CANNOT just go and update the headers on files unless Greg is the only
author and all other non trivial contributors have signed some form of
CLA.  I would feel very uncomfortable signing off on a release without a
review of these files that got changed, disclaimer or not.


Is it enough that if the following criteria meet:
1.The file is BSD license
2.The file is created by Greg
3.The file state that Greg is one and only one owner
Then we can convert it's license to Apache.


This was stated by a mentor in the past.  So, based on that, yes, I 
believe that that is all that is required.

Re: Build errors with inline functions

[Gregory Nutt]

In C, if placing a function in a header, "static inline" is needed to avoid
a "multiple definitions" problem, but means that if the compiler decides
*not* to inline the function, and if the function is used from multiple C
modules, then some code bloat results because you could end up with
multiple copies of the object code in your executable. But I consider this
to be a negligible problem because you should not make functions inline
unless they're really short and simple anyway.


I was recently working with a platform that has only a C89 compiler.  
There was incredible code bloat and I found that code had bloated by 80% 
due to static inline functions.  I fixed these (not very elegantly) and 
the the size was a little more managable but still to large (I expect 
there are others)


See commit 3b53cd1e578de1e6bddfae605452a77323e5a70b

I think we should get all static inline functions at least out of common 
header files.

Re: Apache 2.0 License headers in source files

[Brennan Ashton]

On Fri, Mar 20, 2020, 8:01 AM Gregory Nutt  wrote:

>
> >> We CANNOT just go and update the headers on files unless Greg is the
> only
> >> author and all other non trivial contributors have signed some form of
> >> CLA.  I would feel very uncomfortable signing off on a release without a
> >> review of these files that got changed, disclaimer or not.
> >>
> > Is it enough that if the following criteria meet:
> > 1.The file is BSD license
> > 2.The file is created by Greg
> > 3.The file state that Greg is one and only one owner
> > Then we can convert it's license to Apache.
>
> This was stated by a mentor in the past.  So, based on that, yes, I
> believe that that is all that is required.


This is not accurate based on what Justin has said and goes against what I
know about OSS licensing.  This is exactly why we have CLAs, the copyright
header does not give you rights to my contribution.

I would love to be wrong, so if a mentor can comment on this please correct
me.

--Brennan

Re: Apache 2.0 License headers in source files

[Nathan Hartman]

On Fri, Mar 20, 2020 at 10:37 AM Brennan Ashton
 wrote:
> On Fri, Mar 20, 2020, 7:29 AM Nathan Hartman 
> wrote:
> > I'd like to nudge (or pehaps push and shove) Apache NuttX toward
> > making our first release as an Apache podling. Along those lines I'd
> > like to revive this conversation...
>
> Personally I got a little turned away on this when we had the conversation
> to work on this and start a path forward and immediately PRs got merged
> including one I commented on that violated the plan. This is a difficult
> task and we should not be making it harder on ourselves.

Can we let bygones be bygones and chart a path forward from where we
are? Regarding PRs, should we temporarily stop merging any PRs (except
bug-fixes) and focus everyone's efforts on licensing only? In other
words, what specifically do you need from the rest of the PPMC?

More below:

On Fri, Mar 20, 2020 at 11:01 AM Gregory Nutt  wrote:
> >> We CANNOT just go and update the headers on files unless Greg is the only
> >> author and all other non trivial contributors have signed some form of
> >> CLA.  I would feel very uncomfortable signing off on a release without a
> >> review of these files that got changed, disclaimer or not.
> >>
> > Is it enough that if the following criteria meet:
> > 1.The file is BSD license
> > 2.The file is created by Greg
> > 3.The file state that Greg is one and only one owner
> > Then we can convert it's license to Apache.
>
> This was stated by a mentor in the past.  So, based on that, yes, I
> believe that that is all that is required.

I think Brennan is talking about files that were changed to Apache 2.0
headers that possibly shouldn't have. So, I suggest that those should
be re-checked.

I think we need some sort of code we can 'grep' for, that we'll put in
each source file as we process it. We need three different codes:
o "LICENSE-CHANGE-RECHECK" -- means "this file has a Apache 2.0 header
but that's sketchy so we need to re-check it"
o "LICENSE-CHANGE-COMPLETE" -- means "this file has been checked and
cleared" (and it has a Apache 2.0 header)
o "LICENSE-CHANGE-PENDING" -- means "this file has complicated
licensing that needs to be sorted out"

The idea being to handle all the "low hanging fruits" first and then
deal with all the "complicated licensing" ones later. Thoughts on
that?

More below:

On Fri, Mar 20, 2020 at 10:46 AM Gregory Nutt  wrote:
> The last release, 8.2, was from mid-November 2019.  Releases had been
> been made religiously every two months for years up until 8.2. We are
> approaching 6 months with no releases.  I am sure that the community is
> well aware of this.

I am well aware of this; hence, I think we all need to start pushing
in this direction. We *need* to get back on track with scheduled
releases (we can, as a community, decide if we want that to be every 2
months, or every N months, but we need to make that decision and then
stick to it).

Nathan

Re: Build errors with inline functions

[Xiang Xiao]

On Fri, Mar 20, 2020 at 11:07 PM Gregory Nutt  wrote:
>
>
> > In C, if placing a function in a header, "static inline" is needed to avoid
> > a "multiple definitions" problem, but means that if the compiler decides
> > *not* to inline the function, and if the function is used from multiple C
> > modules, then some code bloat results because you could end up with
> > multiple copies of the object code in your executable. But I consider this
> > to be a negligible problem because you should not make functions inline
> > unless they're really short and simple anyway.
>
> I was recently working with a platform that has only a C89 compiler.
> There was incredible code bloat and I found that code had bloated by 80%
> due to static inline functions.  I fixed these (not very elegantly) and
> the the size was a little more managable but still to large (I expect
> there are others)
>
> See commit 3b53cd1e578de1e6bddfae605452a77323e5a70b
>
> I think we should get all static inline functions at least out of common
> header files.
>

If we want to support the compiler which don't support inline, it's better that:
1.Remove CONFIG_HAVE_INLINE from include/nuttx/compiler.h
2.Convert inline fucntion to macro to normal function
It isn't hard to fix because grep just can find inline about 100 times.

Re: Apache 2.0 License headers in source files

[Gregory Nutt]

We CANNOT just go and update the headers on files unless Greg is the

only

author and all other non trivial contributors have signed some form of
CLA.  I would feel very uncomfortable signing off on a release without a
review of these files that got changed, disclaimer or not.


Is it enough that if the following criteria meet:
1.The file is BSD license
2.The file is created by Greg
3.The file state that Greg is one and only one owner
Then we can convert it's license to Apache.

This was stated by a mentor in the past.  So, based on that, yes, I
believe that that is all that is required.


This is not accurate based on what Justin has said and goes against what I
know about OSS licensing.  This is exactly why we have CLAs, the copyright
header does not give you rights to my contribution.

I would love to be wrong, so if a mentor can comment on this please correct
me.


There are these comments from Justin Mclean in this mailing list in 
regard to PRs.  I won't try to track all of these down.  Here is one 
from https://github.com/apache/incubator-nuttx/pull/528


   HI,

   The word COPYRIGHT will appear in the BSD license, but not other
   form of the word copyright should appear in the file. I think if
   there is only one Copyright and the name matches, we can change the
   license

   I’m not sure this a valid assumption, it is for BSD files copyright
   Gregory Nutt but for for 3rd party files with a single copyright
   please do not change these. Also it not considering the case where a
   BSD license header may of incorrectly been placed on a file. This is
   because ASF policy is slightly different to how the project has
   previously treated 3rd party files. As I said before I would
   strongly recommend not using a script like this to replace the
   headers. Thanks, Justin

But there are probably a dozen others.

The effort to change all of my BSD-3 headers to Apache has been going on 
a very low level since January or February.  Perhaps a few hundred 
(probably fewer) have been changed change based on guidance from our 
mentors which we are trying to follow with 100% precision.  We have 
backed away that somewhat in the past couple of weeks since following 
our mentor's guidance is apparently causing bad feelings.


Greg

Re: Build errors with inline functions

[Gregory Nutt]

If we want to support the compiler which don't support inline, it's better that:
1.Remove CONFIG_HAVE_INLINE from include/nuttx/compiler.h
2.Convert inline fucntion to macro to normal function
It isn't hard to fix because grep just can find inline about 100 times.
There are inline functions in common C files which are not a problem 
because we have the definitions in compiler.h.  The use in header files 
is causing all of the problems.

Re: Apache 2.0 License headers in source files

[Brennan Ashton]

On Fri, Mar 20, 2020, 8:19 AM Gregory Nutt  wrote:

>
>  We CANNOT just go and update the headers on files unless Greg is the
> >> only
>  author and all other non trivial contributors have signed some form of
>  CLA.  I would feel very uncomfortable signing off on a release
> without a
>  review of these files that got changed, disclaimer or not.
> 
> >>> Is it enough that if the following criteria meet:
> >>> 1.The file is BSD license
> >>> 2.The file is created by Greg
> >>> 3.The file state that Greg is one and only one owner
> >>> Then we can convert it's license to Apache.
> >> This was stated by a mentor in the past.  So, based on that, yes, I
> >> believe that that is all that is required.
> >
> > This is not accurate based on what Justin has said and goes against what
> I
> > know about OSS licensing.  This is exactly why we have CLAs, the
> copyright
> > header does not give you rights to my contribution.
> >
> > I would love to be wrong, so if a mentor can comment on this please
> correct
> > me.
>
> There are these comments from Justin Mclean in this mailing list in
> regard to PRs.  I won't try to track all of these down.  Here is one
> from https://github.com/apache/incubator-nuttx/pull/528
>
> HI,
>
> The word COPYRIGHT will appear in the BSD license, but not other
> form of the word copyright should appear in the file. I think if
> there is only one Copyright and the name matches, we can change the
> license
>
> I’m not sure this a valid assumption, it is for BSD files copyright
> Gregory Nutt but for for 3rd party files with a single copyright
> please do not change these. Also it not considering the case where a
> BSD license header may of incorrectly been placed on a file. This is
> because ASF policy is slightly different to how the project has
> previously treated 3rd party files. As I said before I would
> strongly recommend not using a script like this to replace the
> headers. Thanks, Justin
>
> But there are probably a dozen others.
>
> The effort to change all of my BSD-3 headers to Apache has been going on
> a very low level since January or February.  Perhaps a few hundred
> (probably fewer) have been changed change based on guidance from our
> mentors which we are trying to follow with 100% precision.  We have
> backed away that somewhat in the past couple of weeks since following
> our mentor's guidance is apparently causing bad feelings.
>
> Greg
>

See the three comments here:
https://github.com/apache/incubator-nuttx/pull/528#issuecomment-597485223

Which I believe is also in agreement with Adams understanding is as well.

It is going to be a long path if this is the case but I think if we setup a
process and work through the difference subsystems (Adam has suggested the
scheduler) methodically it won't be too bad. I would just like to see us do
even one little bit as part of this release and call it progress in the
right direction.


As for stopping PRs I think long as people has ICLAs or are minor bug
fixes, it's fine but we should avoid changing headers except on new files.

--Brennan

>

Re: Apache 2.0 License headers in source files

[Adam Feuer]

For the license clearing part, I think the next piece of work to do is
license clearing for all the files under sched/ as a test of this process:

https://cwiki.apache.org/confluence/display/NUTTX/License+Clearing

As noted in a previous email, there are:

   - 285 total files
   - 114 files have only commits from people listed as NuttX committers
   - 171 files have commits from a mix of NuttX committers and
   non-committers

This should take a few hours to go through the committer-only files and
make sure there's no other copyrights in them. Once they're cleared, we can
generate a CSV report of cleared files, then run the licenseheader script
to update the headers, and submit a license-header-only PR. I fixed the
licenseheader.py tool to preseve file description if present.

I'm willing to spend a couple of hours on it this weekend. If Brennan is
also, we should be able to have that PR ready to review Monday. Once it's
accepted, we will have done an end-to-end run-through of the easy path. Is
that enough progress for a release?

Then we can run the same process on the hard path, the one with committers
and non-committers, and send emails to get ICLAs from the contributors.
Once we have done that, I would try this on one other area (maybe fs? it
has 178 C files). Then try to do everything remaining, targeting the
contributors who have committed the most code... but as Brennan says, we
can do that process in future releases.

-adam


On Fri, Mar 20, 2020 at 8:29 AM Brennan Ashton 
wrote:

> On Fri, Mar 20, 2020, 8:19 AM Gregory Nutt  wrote:
>
> >
> >  We CANNOT just go and update the headers on files unless Greg is the
> > >> only
> >  author and all other non trivial contributors have signed some form
> of
> >  CLA.  I would feel very uncomfortable signing off on a release
> > without a
> >  review of these files that got changed, disclaimer or not.
> > 
> > >>> Is it enough that if the following criteria meet:
> > >>> 1.The file is BSD license
> > >>> 2.The file is created by Greg
> > >>> 3.The file state that Greg is one and only one owner
> > >>> Then we can convert it's license to Apache.
> > >> This was stated by a mentor in the past.  So, based on that, yes, I
> > >> believe that that is all that is required.
> > >
> > > This is not accurate based on what Justin has said and goes against
> what
> > I
> > > know about OSS licensing.  This is exactly why we have CLAs, the
> > copyright
> > > header does not give you rights to my contribution.
> > >
> > > I would love to be wrong, so if a mentor can comment on this please
> > correct
> > > me.
> >
> > There are these comments from Justin Mclean in this mailing list in
> > regard to PRs.  I won't try to track all of these down.  Here is one
> > from https://github.com/apache/incubator-nuttx/pull/528
> >
> > HI,
> >
> > The word COPYRIGHT will appear in the BSD license, but not other
> > form of the word copyright should appear in the file. I think if
> > there is only one Copyright and the name matches, we can change the
> > license
> >
> > I’m not sure this a valid assumption, it is for BSD files copyright
> > Gregory Nutt but for for 3rd party files with a single copyright
> > please do not change these. Also it not considering the case where a
> > BSD license header may of incorrectly been placed on a file. This is
> > because ASF policy is slightly different to how the project has
> > previously treated 3rd party files. As I said before I would
> > strongly recommend not using a script like this to replace the
> > headers. Thanks, Justin
> >
> > But there are probably a dozen others.
> >
> > The effort to change all of my BSD-3 headers to Apache has been going on
> > a very low level since January or February.  Perhaps a few hundred
> > (probably fewer) have been changed change based on guidance from our
> > mentors which we are trying to follow with 100% precision.  We have
> > backed away that somewhat in the past couple of weeks since following
> > our mentor's guidance is apparently causing bad feelings.
> >
> > Greg
> >
>
> See the three comments here:
> https://github.com/apache/incubator-nuttx/pull/528#issuecomment-597485223
>
> Which I believe is also in agreement with Adams understanding is as well.
>
> It is going to be a long path if this is the case but I think if we setup a
> process and work through the difference subsystems (Adam has suggested the
> scheduler) methodically it won't be too bad. I would just like to see us do
> even one little bit as part of this release and call it progress in the
> right direction.
>
>
> As for stopping PRs I think long as people has ICLAs or are minor bug
> fixes, it's fine but we should avoid changing headers except on new files.
>
> --Brennan
>
> >
>


-- 
Adam Feuer 

Breakout apps/ ?

[Gregory Nutt]

Hi, group,

There has been talk for years about the idea of creating a separate 
project out of apps/, extending it so that it is a real NuttX 
"Distribution," basically like OpenEmbedded, Buildroot, or Yocto for 
NuttX.  It would:


 *   Download and install the NuttX
 *   Select and build the custom firmware

I have always thought this was a novel idea, but I have not particularly 
been an advocate.  But I think that Apache licensing issues might drive 
us to reconsider this idea.  The nuttx/ repository is really pretty 
clean.  There is certainly some bits of third party code and certainly 
some ICLAs will be needed, but the code is really very clean.


You cannot say this about apps.  apps/ is a collection of code with a 
lot of third party code.  There are full ports of third party 
applications (like interprers/bas, or netutils/thttpd, or modbus, or 
wapi, or ...).  There are original applications (like NSH).  And there 
is all manner of things in between.   Mostlyare original applications 
with varying amounts of highly modified third party code.  NxWidgets 
contains some Whoopsi code, for example.


So perhaps we could simply things by pulling some or all of the apps/ 
out of the NuttX repositories.  There apps/ are NOT the OS. They are a 
hodge-podge collection of applications that runs on the OS.  The OS in 
the nuttx/repository stands alone and does not depend on the existence 
of apps/. So there is no imperative reason that we should retain apps/ 
in the nuttx/ respository.


Certainly doing so is a convenience.  But if licensing becomes an issue, 
then we should consider some options:


 * We could pull the entire apps/ repository out of the Apache
   repositories and manage it as a separate project outside of Apache. 
   This would be the cleanest way to deliver a complete NuttX
   distribution in the spririt of OpenEmbedded or Buildroot. But there
   are some cons:  The build system and PR checks depend on the
   existing configuration and such a change would potentially cause
   breakage or complexity.  Some of the applications such as NSH really
   are very connected to the OS. Finally, there is no project structure
   in place to manage such a NuttX distribution.
 * We could also just move any dubious components out of apps/ and into
   a separate repository/project.  As components that could be
   installed in apps/.  This use case would be awkward and there is
   really no way to develop a "Distribution" from this.
 * Finally, we can do nothing and deal with the third party software in
   apps/ as we encountered it.

Thoughts?

Greg

Re: Breakout apps/ ?

[Alan Carvalho de Assis]

Hi Greg,

I agree with this idea! A NuttX distribution makes sense and will
avoid licensing issues, we could let the user to select which licenses
he accept to use.

BR,

Alan

On 3/20/20, Gregory Nutt  wrote:
> Hi, group,
>
> There has been talk for years about the idea of creating a separate
> project out of apps/, extending it so that it is a real NuttX
> "Distribution," basically like OpenEmbedded, Buildroot, or Yocto for
> NuttX.  It would:
>
>   *   Download and install the NuttX
>   *   Select and build the custom firmware
>
> I have always thought this was a novel idea, but I have not particularly
> been an advocate.  But I think that Apache licensing issues might drive
> us to reconsider this idea.  The nuttx/ repository is really pretty
> clean.  There is certainly some bits of third party code and certainly
> some ICLAs will be needed, but the code is really very clean.
>
> You cannot say this about apps.  apps/ is a collection of code with a
> lot of third party code.  There are full ports of third party
> applications (like interprers/bas, or netutils/thttpd, or modbus, or
> wapi, or ...).  There are original applications (like NSH).  And there
> is all manner of things in between.   Mostlyare original applications
> with varying amounts of highly modified third party code.  NxWidgets
> contains some Whoopsi code, for example.
>
> So perhaps we could simply things by pulling some or all of the apps/
> out of the NuttX repositories.  There apps/ are NOT the OS. They are a
> hodge-podge collection of applications that runs on the OS.  The OS in
> the nuttx/repository stands alone and does not depend on the existence
> of apps/. So there is no imperative reason that we should retain apps/
> in the nuttx/ respository.
>
> Certainly doing so is a convenience.  But if licensing becomes an issue,
> then we should consider some options:
>
>   * We could pull the entire apps/ repository out of the Apache
> repositories and manage it as a separate project outside of Apache.
> This would be the cleanest way to deliver a complete NuttX
> distribution in the spririt of OpenEmbedded or Buildroot. But there
> are some cons:  The build system and PR checks depend on the
> existing configuration and such a change would potentially cause
> breakage or complexity.  Some of the applications such as NSH really
> are very connected to the OS. Finally, there is no project structure
> in place to manage such a NuttX distribution.
>   * We could also just move any dubious components out of apps/ and into
> a separate repository/project.  As components that could be
> installed in apps/.  This use case would be awkward and there is
> really no way to develop a "Distribution" from this.
>   * Finally, we can do nothing and deal with the third party software in
> apps/ as we encountered it.
>
> Thoughts?
>
> Greg
>
>
>

Re: PR and issue Templates

[Abdelatif Guettouche]

>
> @mentors Do we have the ability to add a Git hub PR and Issue template?
>
There at least one project using this:
https://github.com/apache/incubator-tvm/blob/master/.github/PULL_REQUEST_TEMPLATE.md
I didn't go through all the Apache projects, maybe there are others.

What do you think should be added in a PR template in our case? Does a
phrase like the one from the link above suffice?
Issues template can be more populated with different templates for bug
reports, help request, etc.


On Fri, Mar 20, 2020 at 12:48 PM David Sidrane 
wrote:

> Hi,
>
>
>
> We spend a lot of time on PRs repeating ourselves on format, license.
>
>
>
> Giving directed links and examples will not challenge contributors with
> having to ferret this out on their own.
>
>
>
> @mentors Do we have the ability to add a Git hub PR and Issue template?
>
>
>
> David
>
>
>
>
>
>
>
> *From:* Abdelatif Guettouche [mailto:notificati...@github.com]
> *Sent:* Friday, March 20, 2020 4:42 AM
> *To:* apache/incubator-nuttx
> *Cc:* David Sidrane; Mention
> *Subject:* Re: [apache/incubator-nuttx] Support for Litex VexRiscV (#595)
>
>
>
> @aenrbs New files need to have an Apache license. Kconfig, README and auto
> generated files like defconfig don't need a license.
> Note that the license holder in all of this PRs files is Gregory Nutt.
> Gregory Nutt has already submitted an ICLA and gave his approval to change
> his license header.
>
> @davids5  As of now, we don't. Some has
> adopted
> their own templates when submitting PRs.
> We may want to add Github's templates for PRs/Issues. Maybe we bring this
> to the dev list for a discussion on what should be there?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
>  >,
> or unsubscribe
> <
> https://github.com/notifications/unsubscribe-auth/AAO3BXP3H2FN5LPATMWNSNTRINJCJANCNFSM4LQFCQSA
> >
> .
>

Re: PR and issue Templates

[Adam Feuer]

Here's the template I've used before in PRs on other projects, I found it
helps to encourage people submitting PRs to fill out all relevant sections:

### Summary
* bullet point form
* is easier to read
### Impact
### Limitations / TODO
### Detail
### Testing
### How To Verify

Here's the process I wrote for myself to follow when submitting a PR... a
"cheat sheet":

https://nuttx-companion.readthedocs.io/en/latest/user/contributing.html

-adam




On Fri, Mar 20, 2020 at 12:01 PM Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:

> >
> > @mentors Do we have the ability to add a Git hub PR and Issue template?
> >
> There at least one project using this:
>
> https://github.com/apache/incubator-tvm/blob/master/.github/PULL_REQUEST_TEMPLATE.md
> I didn't go through all the Apache projects, maybe there are others.
>
> What do you think should be added in a PR template in our case? Does a
> phrase like the one from the link above suffice?
> Issues template can be more populated with different templates for bug
> reports, help request, etc.
>
>
> On Fri, Mar 20, 2020 at 12:48 PM David Sidrane 
> wrote:
>
> > Hi,
> >
> >
> >
> > We spend a lot of time on PRs repeating ourselves on format, license.
> >
> >
> >
> > Giving directed links and examples will not challenge contributors with
> > having to ferret this out on their own.
> >
> >
> >
> > @mentors Do we have the ability to add a Git hub PR and Issue template?
> >
> >
> >
> > David
> >
> >
> >
> >
> >
> >
> >
> > *From:* Abdelatif Guettouche [mailto:notificati...@github.com]
> > *Sent:* Friday, March 20, 2020 4:42 AM
> > *To:* apache/incubator-nuttx
> > *Cc:* David Sidrane; Mention
> > *Subject:* Re: [apache/incubator-nuttx] Support for Litex VexRiscV (#595)
> >
> >
> >
> > @aenrbs New files need to have an Apache license. Kconfig, README and
> auto
> > generated files like defconfig don't need a license.
> > Note that the license holder in all of this PRs files is Gregory Nutt.
> > Gregory Nutt has already submitted an ICLA and gave his approval to
> change
> > his license header.
> >
> > @davids5  As of now, we don't. Some has
> > adopted
> > their own templates when submitting PRs.
> > We may want to add Github's templates for PRs/Issues. Maybe we bring this
> > to the dev list for a discussion on what should be there?
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <
> https://github.com/apache/incubator-nuttx/pull/595#issuecomment-601657889
> > >,
> > or unsubscribe
> > <
> >
> https://github.com/notifications/unsubscribe-auth/AAO3BXP3H2FN5LPATMWNSNTRINJCJANCNFSM4LQFCQSA
> > >
> > .
> >
>


-- 
Adam Feuer 

Re: Podling Nuttx Report Reminder - April 2020

[Adam Feuer]

What blocks us from doing a release right now? I've heard a few things:

   - parallel build is broken
   - no progress on license clearing

Are these correct? If not, what do we need to add or change to get a
release out? If people reply to this thread, I will summarize and create a
checklist in a wiki page for us to follow.

Can we release without parallel build being fixed? Maybe manually? If we
run a test clearing process on the files under sched/ like I outlined, will
that be enough progress to make a release? What else do we need if anything?

-adam

On Fri, Mar 20, 2020 at 5:20 AM Justin Mclean 
wrote:

> Hi,
>
> > Will this help us make progress?
>
> If you don’t want to report then that’s up to you.
>
> > We've been more or less repeating the same thing for the past two
> reports.
>
> Which is a concern.
>
> > Technically the project is making progress
>
> Which the ASF is not so concerned about, what you need to show and report
> on is how the community grows or is encouraged to grow.
>
> >  We may need some time to get everything in track.
>
> IMO you have had  time to do this, Some projects are slow to start but I
> think this project IMO is focusing on the wrong things. If the project
> continues down this track it is on I will have no choice but to resign as a
> mentor.
>
> Thanks,
> Justin



-- 
Adam Feuer 

Re: Podling Nuttx Report Reminder - April 2020

[Gregory Nutt]

What blocks us from doing a release right now? I've heard a few things:

- parallel build is broken
- no progress on license clearing


Single biggest reason:  No release manager to manage the release process

Re: Podling Nuttx Report Reminder - April 2020

[Brennan Ashton]

On Fri, Mar 20, 2020, 12:21 PM Gregory Nutt  wrote:

>
> > What blocks us from doing a release right now? I've heard a few things:
> >
> > - parallel build is broken
> > - no progress on license clearing
>
> Single biggest reason:  No release manager to manage the release process
>

I have volunteered to do this multiple times but my condition is some
progress on the licensing issue even if it is just a small amount.

My worry as I said earlier today is we not have Apache headers on files
that I do not think we can say should have them. I don't see how we can
sign off on a release with that being the case.

--Brennan

>

Re: Podling Nuttx Report Reminder - April 2020

[Adam Feuer]

Brennan,

I'm willing to put a couple hours this weekend into Fossology, updating
license headers for the files we clear, and making a PR to revidew. Are you
willing to spend a couple of hours this weekend with me to help? I think if
we coordinate our work, it doesn't have to be at the same time.

-adam

On Fri, Mar 20, 2020 at 12:24 PM Brennan Ashton 
wrote:

> On Fri, Mar 20, 2020, 12:21 PM Gregory Nutt  wrote:
>
> >
> > > What blocks us from doing a release right now? I've heard a few things:
> > >
> > > - parallel build is broken
> > > - no progress on license clearing
> >
> > Single biggest reason:  No release manager to manage the release process
> >
>
> I have volunteered to do this multiple times but my condition is some
> progress on the licensing issue even if it is just a small amount.
>
> My worry as I said earlier today is we not have Apache headers on files
> that I do not think we can say should have them. I don't see how we can
> sign off on a release with that being the case.
>
> --Brennan
>
> >
>


-- 
Adam Feuer 

Re: Podling Nuttx Report Reminder - April 2020

[Brennan Ashton]

On Fri, Mar 20, 2020, 12:34 PM Adam Feuer  wrote:

> Brennan,
>
> I'm willing to put a couple hours this weekend into Fossology, updating
> license headers for the files we clear, and making a PR to revidew. Are you
> willing to spend a couple of hours this weekend with me to help? I think if
> we coordinate our work, it doesn't have to be at the same time.
>
> -adam
>

Sounds good to me, can't go anywhere anyway this weekend.

--Brennan

>

Re: Podling Nuttx Report Reminder - April 2020

[Adam Feuer]

> Sounds good to me, can't go anywhere anyway this weekend.
>

Yeah neither can I.

Ok, let's coordinate off-list.

-adam
-- 
Adam Feuer 

RE: PR and issue Templates

[David Sidrane]

Here are some that work well for issues.

https://github.com/PX4/Firmware/tree/master/.github/ISSUE_TEMPLATE

For PR's
We could add the requirement for License on new files with links to Our
template.
We could add the requirement for {I|C}CLA with links to
https://www.apache.org/licenses/contributor-agreements.html.
We can add a link to how to run the CS tool with tips on how to resolve
issues with it.
And add the Always quoted
https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard

David



-Original Message-
From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
Sent: Friday, March 20, 2020 12:56 PM
To: dev@nuttx.apache.org
Subject: Re: PR and issue Templates

>
> @mentors Do we have the ability to add a Git hub PR and Issue template?
>
There at least one project using this:
https://github.com/apache/incubator-tvm/blob/master/.github/PULL_REQUEST_TEMPLATE.md
I didn't go through all the Apache projects, maybe there are others.

What do you think should be added in a PR template in our case? Does a
phrase like the one from the link above suffice?
Issues template can be more populated with different templates for bug
reports, help request, etc.


On Fri, Mar 20, 2020 at 12:48 PM David Sidrane 
wrote:

> Hi,
>
>
>
> We spend a lot of time on PRs repeating ourselves on format, license.
>
>
>
> Giving directed links and examples will not challenge contributors with
> having to ferret this out on their own.
>
>
>
> @mentors Do we have the ability to add a Git hub PR and Issue template?
>
>
>
> David
>
>
>
>
>
>
>
> *From:* Abdelatif Guettouche [mailto:notificati...@github.com]
> *Sent:* Friday, March 20, 2020 4:42 AM
> *To:* apache/incubator-nuttx
> *Cc:* David Sidrane; Mention
> *Subject:* Re: [apache/incubator-nuttx] Support for Litex VexRiscV (#595)
>
>
>
> @aenrbs New files need to have an Apache license. Kconfig, README and auto
> generated files like defconfig don't need a license.
> Note that the license holder in all of this PRs files is Gregory Nutt.
> Gregory Nutt has already submitted an ICLA and gave his approval to change
> his license header.
>
> @davids5  As of now, we don't. Some has
> adopted
> their own templates when submitting PRs.
> We may want to add Github's templates for PRs/Issues. Maybe we bring this
> to the dev list for a discussion on what should be there?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
>  >,
> or unsubscribe
> <
> https://github.com/notifications/unsubscribe-auth/AAO3BXP3H2FN5LPATMWNSNTRINJCJANCNFSM4LQFCQSA
> >
> .
>

Re: Build errors with inline functions

[John Rippetoe]

I think at a minimum, we need to conditionally include mpu.h only when 
the MPU support is actually needed. Options for that are CONFIG_ARM_MPU, 
CONFIG_ARCH_USE_MPU, or CONFIG_BUILD_PROTECTED. If we use either of the 
first two, the error will crop back up if MPU support is enabled without 
also performing a protected build since up_mpu.c is only included in a 
protected build. I know that it is possible to enable MPU support 
without performing a protected build, but is there any use case for 
this? If not, it seems odd that these would be separate options. But if 
there is, then we need to figure out how to get the build to compile in 
that scenario. That might be as simple as including up_mpu.c whenever 
MPU support is enabled as opposed to only doing so when a protected 
build is requested. Someone with more knowledge on how these two 
features interact would be a better source of info on that than I am.


On 3/20/20 11:21 AM, Gregory Nutt wrote:


If we want to support the compiler which don't support inline, it's 
better that:

1.Remove CONFIG_HAVE_INLINE from include/nuttx/compiler.h
2.Convert inline fucntion to macro to normal function
It isn't hard to fix because grep just can find inline about 100 times.
There are inline functions in common C files which are not a problem 
because we have the definitions in compiler.h.  The use in header 
files is causing all of the problems.

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: Build errors with inline functions

[John Rippetoe]

You can try removing the static from the inline function definitions 
in the header file.  The code should then compile, however, you could 
also get multiply defined functions at link time... Or maybe the 
linker is smart enough to allow multiples???


Putting inline functions in header files introduces lots of problem 
(especially if you are using C89).  If they are to be used in header 
files, at least they should not be declared static.


Removing static didn't change anything, which makes sense given that no 
optimization is happening and the inline keyword is being removed by the 
mechanism in compiler.h


Adding the always_inline attribute worked, but only when static was 
still attached.


All of these issues go away when the standard is set as C99, so the 
compiler must be trimming the functions out in this scenario.




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: Build errors with inline functions

[David Sidrane]

> the error will crop back up if MPU support is enabled without also
> performing a protected build since up_mpu.c is only included in a
> protected build.

Just a heads up there are some case on some HW (imxrt, maybe the K66 for the
DMA) were the MPU is needed to enable the proper access but not in protected
build.

ifeq ($(CONFIG_ARM_MPU),y)
  ifneq ($(CONFIG_BUILD_PROTECTED),y)
CMN_CSRCS += up_mpu.c
  endif
CHIP_CSRCS += imxrt_mpuinit.c
  ifeq ($(CONFIG_BUILD_PROTECTED),y)
CHIP_CSRCS += imxrt_userspace.c
  endif
endif

-Original Message-
From: John Rippetoe [mailto:jrippe...@roboticresearch.com]
Sent: Friday, March 20, 2020 2:09 PM
To: dev@nuttx.apache.org
Subject: Re: Build errors with inline functions

I think at a minimum, we need to conditionally include mpu.h only when
the MPU support is actually needed. Options for that are CONFIG_ARM_MPU,
CONFIG_ARCH_USE_MPU, or CONFIG_BUILD_PROTECTED. If we use either of the
first two, the error will crop back up if MPU support is enabled without
also performing a protected build since up_mpu.c is only included in a
protected build. I know that it is possible to enable MPU support
without performing a protected build, but is there any use case for
this? If not, it seems odd that these would be separate options. But if
there is, then we need to figure out how to get the build to compile in
that scenario. That might be as simple as including up_mpu.c whenever
MPU support is enabled as opposed to only doing so when a protected
build is requested. Someone with more knowledge on how these two
features interact would be a better source of info on that than I am.

On 3/20/20 11:21 AM, Gregory Nutt wrote:
>
>> If we want to support the compiler which don't support inline, it's
>> better that:
>> 1.Remove CONFIG_HAVE_INLINE from include/nuttx/compiler.h
>> 2.Convert inline fucntion to macro to normal function
>> It isn't hard to fix because grep just can find inline about 100 times.
> There are inline functions in common C files which are not a problem
> because we have the definitions in compiler.h.  The use in header
> files is causing all of the problems.
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: Apache 2.0 License headers in source files

[Justin Mclean]

Hi,

INAL but the copyright notice in the header is just a claim and may not reflect 
who actually has copyright. It doesn’t mean that that person or company owns 
the copyright on the entire file. With a company it’s usually easier as 
employment contracts say the company owns the copyright of works produced by 
their workers. With individuals it gets more complex as they may or may not own 
the copyright or may be unaware who does. (Worse case scenario see [1], where 
an employee was forced to implement an idea he had outside of work unpaid and 
had to pay costs)

Each person who made changes would own copyright (or for their company) 
automatically on their work. Especially in this case where I believe the 
project had no ICLAs or agreements in place with it contributors about 
copyright. If you a more qualified opinion please ask on legal-discuss.

We know this is currently an issue, so I would you just note that it is in the 
work in progress DISCLAIMER for the initial release, so that way people who use 
the release are aware of it. Given the licensing terms of the files it’s not an 
issue that would stop most people from using the software.

What Brennan and Adam are suggesting sounds like a good process to me. 
Identifying all of the contributors that don’t have ICLA is useful, it’s also 
good to has some ideas of the size of their contribution. For large 
contributions it would be best to get an ICLA from the individual, this may be 
a lot of work, and in some cases it may not be possible. That fine we can deal 
with that as needed and this shouldn’t hold up a release or graduation (as long 
as progress is being made) and can be done in parallel.

A release could have been made at any point in the last several months, the 
only barriers to not do so that are ones you are putting up for yourself. A 
release doesn’t have to be perfect, in fact it doesn’t even have to work as far 
as the ASF is concerned. A good goal to aim for it to make each release better 
than the last, and release frequently rather than trying to make a perfect 
release.

Thanks,
Justin

1. https://www.chicagotribune.com/news/ct-xpm-2002-08-05-0208050013-story.html

Re: Apache 2.0 License headers in source files

[Adam Feuer]

Thanks Justin. I think Brennan is volunteering to be release manager and
get the next one out, as long as we can start a license clearing process
and make things a little better (become more Apache-like :) ) each release.
Here's what Brennan and I are planning for this weekend:

   1. We're going to work on the scheduler module (nuttx/sched/)
   2. Some recent changes were made to license headers under that
   directory. We're going to go back in time to before those changes...
   3. Brennan will use Fossology to generate license reports for the files
   under sched/
   4. I will find the set of C files that only have NuttX committers (who
   we should have ICLAs from)
   5. We will check this set of files manually and against the Fossology
   report
   6. For the files that are BSD license and have authors that are NuttX
   committers, we'll change the license headers and commit the result to a
   branch.
   7. I will create a PR for this change, and we can use the PR to discuss
   next steps.
   8. Once it's merged, Brennan will work to get the release out.

For more info:
https://cwiki.apache.org/confluence/display/NUTTX/License+Clearing

Improvements to this are welcomed.

cheers
adam

On Fri, Mar 20, 2020 at 5:03 PM Justin Mclean 
wrote:

> Hi,
>
> INAL but the copyright notice in the header is just a claim and may not
> reflect who actually has copyright. It doesn’t mean that that person or
> company owns the copyright on the entire file. With a company it’s usually
> easier as employment contracts say the company owns the copyright of works
> produced by their workers. With individuals it gets more complex as they
> may or may not own the copyright or may be unaware who does. (Worse case
> scenario see [1], where an employee was forced to implement an idea he had
> outside of work unpaid and had to pay costs)
>
> Each person who made changes would own copyright (or for their company)
> automatically on their work. Especially in this case where I believe the
> project had no ICLAs or agreements in place with it contributors about
> copyright. If you a more qualified opinion please ask on legal-discuss.
>
> We know this is currently an issue, so I would you just note that it is in
> the work in progress DISCLAIMER for the initial release, so that way people
> who use the release are aware of it. Given the licensing terms of the files
> it’s not an issue that would stop most people from using the software.
>
> What Brennan and Adam are suggesting sounds like a good process to me.
> Identifying all of the contributors that don’t have ICLA is useful, it’s
> also good to has some ideas of the size of their contribution. For large
> contributions it would be best to get an ICLA from the individual, this may
> be a lot of work, and in some cases it may not be possible. That fine we
> can deal with that as needed and this shouldn’t hold up a release or
> graduation (as long as progress is being made) and can be done in parallel.
>
> A release could have been made at any point in the last several months,
> the only barriers to not do so that are ones you are putting up for
> yourself. A release doesn’t have to be perfect, in fact it doesn’t even
> have to work as far as the ASF is concerned. A good goal to aim for it to
> make each release better than the last, and release frequently rather than
> trying to make a perfect release.
>
> Thanks,
> Justin
>
> 1.
> https://www.chicagotribune.com/news/ct-xpm-2002-08-05-0208050013-story.html



-- 
Adam Feuer 

Re: Build errors with inline functions

[Xiang Xiao]

Another example, we use MPU to protect the code section for NOXIP case
in the flat mode.

On Sat, Mar 21, 2020 at 5:41 AM David Sidrane  wrote:
>
> > the error will crop back up if MPU support is enabled without also
> > performing a protected build since up_mpu.c is only included in a
> > protected build.
>
> Just a heads up there are some case on some HW (imxrt, maybe the K66 for the
> DMA) were the MPU is needed to enable the proper access but not in protected
> build.
>
> ifeq ($(CONFIG_ARM_MPU),y)
>   ifneq ($(CONFIG_BUILD_PROTECTED),y)
> CMN_CSRCS += up_mpu.c
>   endif
> CHIP_CSRCS += imxrt_mpuinit.c
>   ifeq ($(CONFIG_BUILD_PROTECTED),y)
> CHIP_CSRCS += imxrt_userspace.c
>   endif
> endif
>
> -Original Message-
> From: John Rippetoe [mailto:jrippe...@roboticresearch.com]
> Sent: Friday, March 20, 2020 2:09 PM
> To: dev@nuttx.apache.org
> Subject: Re: Build errors with inline functions
>
> I think at a minimum, we need to conditionally include mpu.h only when
> the MPU support is actually needed. Options for that are CONFIG_ARM_MPU,
> CONFIG_ARCH_USE_MPU, or CONFIG_BUILD_PROTECTED. If we use either of the
> first two, the error will crop back up if MPU support is enabled without
> also performing a protected build since up_mpu.c is only included in a
> protected build. I know that it is possible to enable MPU support
> without performing a protected build, but is there any use case for
> this? If not, it seems odd that these would be separate options. But if
> there is, then we need to figure out how to get the build to compile in
> that scenario. That might be as simple as including up_mpu.c whenever
> MPU support is enabled as opposed to only doing so when a protected
> build is requested. Someone with more knowledge on how these two
> features interact would be a better source of info on that than I am.
>
> On 3/20/20 11:21 AM, Gregory Nutt wrote:
> >
> >> If we want to support the compiler which don't support inline, it's
> >> better that:
> >> 1.Remove CONFIG_HAVE_INLINE from include/nuttx/compiler.h
> >> 2.Convert inline fucntion to macro to normal function
> >> It isn't hard to fix because grep just can find inline about 100 times.
> > There are inline functions in common C files which are not a problem
> > because we have the definitions in compiler.h.  The use in header
> > files is causing all of the problems.
> 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: Build errors with inline functions

[Xiang Xiao]

On Sat, Mar 21, 2020 at 5:15 AM John Rippetoe
 wrote:
>
>
> >
> > You can try removing the static from the inline function definitions
> > in the header file.  The code should then compile, however, you could
> > also get multiply defined functions at link time... Or maybe the
> > linker is smart enough to allow multiples???
> >
> > Putting inline functions in header files introduces lots of problem
> > (especially if you are using C89).  If they are to be used in header
> > files, at least they should not be declared static.
> >
> Removing static didn't change anything, which makes sense given that no
> optimization is happening and the inline keyword is being removed by the
> mechanism in compiler.h
>
> Adding the always_inline attribute worked, but only when static was
> still attached.
>

always_inline is still a hint to compiler, no 100% guarantee here. For
example, it's very hard to inline the recursive function.

> All of these issues go away when the standard is set as C99, so the
> compiler must be trimming the functions out in this scenario.
>
>
>
> 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.
>

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

[Apache Jenkins Server]

See 

Changes:


--
[...truncated 561.55 KB...]
  Building NuttX...


Configuration/Tool: sim/touchscreen

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/bas

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...

In file included from bas.c:84:0:
bas.c: In function 'bas_interpreter':
bas_fs.c:107:22: warning: 'g_vt100_colormap' defined but not used 
[-Wunused-const-variable=]
 static const uint8_t g_vt100_colormap[8] =
  ^~~~
bas_error.h:110:37: warning: left-hand operand of comma expression has no 
effect [-Wunused-value]
 #define NOSUCHLINE STATIC+40, _("No such line")
 ^
bas.c:2425:52: note: in expansion of macro 'NOSUCHLINE'
   FS_putChars(STDCHANNEL, (NOSUCHLINE));
^~
:4048:16: warning: 'input' defined but not used [-Wunused-function]

Configuration/Tool: sim/mtdpart

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/spiffs

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/ustream

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...

local/local_connect.c: In function 'psock_local_connect':
local/local_connect.c:292:2: warning: #warning Missing logic [-Wcpp]
 #warning Missing logic
  ^~~

Configuration/Tool: sim/userfs

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...

local/local_fifo.c: In function 'local_release_halfduplex':
local/local_fifo.c:449:4: warning: #warning Missing logic [-Wcpp]
 #  warning Missing logic
^~~
local/local_sockif.c: In function 'local_connect':
local/local_sockif.c:550:2: warning: #warning Missing logic [-Wcpp]
 #warning Missing logic
  ^~~
local/local_sockif.c: In function 'local_send':
local/local_sockif.c:695:2: warning: #warning Missing logic [-Wcpp]
 #warning Missing logic
  ^~~
local/local_connect.c: In function 'psock_local_connect':
local/local_connect.c:292:2: warning: #warning Missing logic [-Wcpp]
 #warning Missing logic
  ^~~

Skipping: sim/rpproxy

Configuration/Tool: sim/vpnkit

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...

local/local_fifo.c: In function 'local_release_halfduplex':
local/local_fifo.c:449:4: warning: #warning Missing logic [-Wcpp]
 #  warning Missing logic
^~~
local/local_sockif.c: In function 'local_connect':
local/local_sockif.c:550:2: warning: #warning Missing logic [-Wcpp]
 #warning Missing logic
  ^~~
local/local_sockif.c: In function 'local_send':
local/lo

Re: PR and issue Templates

[Xiang Xiao]

It's a nice feature, who can create a PR? so we can review and merge it.

Thanks
Xiang


On Sat, Mar 21, 2020 at 4:42 AM David Sidrane  wrote:
>
> Here are some that work well for issues.
>
> https://github.com/PX4/Firmware/tree/master/.github/ISSUE_TEMPLATE
>
> For PR's
> We could add the requirement for License on new files with links to Our
> template.
> We could add the requirement for {I|C}CLA with links to
> https://www.apache.org/licenses/contributor-agreements.html.
> We can add a link to how to run the CS tool with tips on how to resolve
> issues with it.
> And add the Always quoted
> https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard
>
> David
>
>
>
> -Original Message-
> From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
> Sent: Friday, March 20, 2020 12:56 PM
> To: dev@nuttx.apache.org
> Subject: Re: PR and issue Templates
>
> >
> > @mentors Do we have the ability to add a Git hub PR and Issue template?
> >
> There at least one project using this:
> https://github.com/apache/incubator-tvm/blob/master/.github/PULL_REQUEST_TEMPLATE.md
> I didn't go through all the Apache projects, maybe there are others.
>
> What do you think should be added in a PR template in our case? Does a
> phrase like the one from the link above suffice?
> Issues template can be more populated with different templates for bug
> reports, help request, etc.
>
>
> On Fri, Mar 20, 2020 at 12:48 PM David Sidrane 
> wrote:
>
> > Hi,
> >
> >
> >
> > We spend a lot of time on PRs repeating ourselves on format, license.
> >
> >
> >
> > Giving directed links and examples will not challenge contributors with
> > having to ferret this out on their own.
> >
> >
> >
> > @mentors Do we have the ability to add a Git hub PR and Issue template?
> >
> >
> >
> > David
> >
> >
> >
> >
> >
> >
> >
> > *From:* Abdelatif Guettouche [mailto:notificati...@github.com]
> > *Sent:* Friday, March 20, 2020 4:42 AM
> > *To:* apache/incubator-nuttx
> > *Cc:* David Sidrane; Mention
> > *Subject:* Re: [apache/incubator-nuttx] Support for Litex VexRiscV (#595)
> >
> >
> >
> > @aenrbs New files need to have an Apache license. Kconfig, README and auto
> > generated files like defconfig don't need a license.
> > Note that the license holder in all of this PRs files is Gregory Nutt.
> > Gregory Nutt has already submitted an ICLA and gave his approval to change
> > his license header.
> >
> > @davids5  As of now, we don't. Some has
> > adopted
> > their own templates when submitting PRs.
> > We may want to add Github's templates for PRs/Issues. Maybe we bring this
> > to the dev list for a discussion on what should be there?
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> >  > >,
> > or unsubscribe
> > <
> > https://github.com/notifications/unsubscribe-auth/AAO3BXP3H2FN5LPATMWNSNTRINJCJANCNFSM4LQFCQSA
> > >
> > .
> >