Re: Bug Tracking

[Gregory Nutt]

 The Mynewt project, for example, has many repositories.  I can 
find the page but I recall that it is on the order of a dozen or so 
repositories.  ...


17

See https://gitbox.apache.org/repos/asf

Re: Bug Tracking

[Gregory Nutt]

Part of the issues to consider is that If you use GitHub issues, having 
multiple repos you may need to enable issues in multiple places. This means 
more to manage and track. Having all issues for multiple repos on a single 
github repo also has issues.


There would certainly be some scalability issues.  The Mynewt project, 
for example, has many repositories.  I can find the page but I recall 
that it is on the order of a dozen or so repositories.  NuttX was, at 
one point, five repositories.  We currently have four (excluding the 
three or four additional non-Apache support repositories)


If the number of repositories becomes large, it is hard to imagine any 
practical way to manage all of the issues with github issues.

Re: [DISCUSS]Bug Tracking

[Gregory Nutt]

I presume that there will be vote coming in the next few days for the 
Bug Tracking solution.  This thread, then, is really the [DISCUSS] 
thread prior to the vote, right?  I have no idea what the voting options 
will be, but we should probably label this as [DISCUSS] so people will 
appreciate that it is important for their opinions to be heard.

Re: Bug Tracking

[Gregory Nutt]

My understanding is that most patch will come via the mailing list anyway and 
it will be mostly up o the PPMX to create and manage the issues for the users.
That is true.  There was one this morning (my time):  "SMTP send mail 
example build failure"

Re: Bug Tracking

[Justin Mclean]

Hi,

> Why can't we use both JIRA and Github, since they are linked?

The downside would be multiple places to look for issues, They are not closely 
linked if you raise an issue in GitHub one doesn’t get raised in JIRA.

My understanding is that most patch will come via the mailing list anyway and 
it will be mostly up o the PPMX to create and manage the issues for the users.

Thanks,
Justin

Re: Bug Tracking

[Abdelatif Guettouche]

Not apposed to any solution.

However, the argument that people not having access to Github is still
out there.
Why can't we use both JIRA and Github, since they are linked?

On Wed, Jan 15, 2020 at 12:50 AM Gregory Nutt  wrote:
>
>
> > Speaking about bugzilla. I know JIRA is linked which is what I proposed
> > first, but got heavily pushed against.
> I didn't perceive things that way.  I recall only Alin having a strong
> position to use github issues.

Re: Bug Tracking

[Gregory Nutt]

Speaking about bugzilla. I know JIRA is linked which is what I proposed
first, but got heavily pushed against.
I didn't perceive things that way.  I recall only Alin having a strong 
position to use github issues.

Re: Bug Tracking

[Brennan Ashton]

Speaking about bugzilla. I know JIRA is linked which is what I proposed
first, but got heavily pushed against.

On Tue, Jan 14, 2020, 4:43 PM Justin Mclean 
wrote:

> Hi,
>
> > I don't believe it has great integration with GitHub (I did not see any
> > mention in infra)
>
> It has some integration e.g. mention a JIRA in a commit message (or PR)
> and it automatically get linked up to that JIRA.
>
> At the ASF Infra manages JIRA so that reduces a little of the load in
> regard to this.
>
> Thanks,
> Justin

Re: Bug Tracking

[Justin Mclean]

Hi,

> I don't believe it has great integration with GitHub (I did not see any
> mention in infra)

It has some integration e.g. mention a JIRA in a commit message (or PR) and it 
automatically get linked up to that JIRA.

At the ASF Infra manages JIRA so that reduces a little of the load in regard to 
this.

Thanks,
Justin

Re: Bug Tracking

[Brennan Ashton]

I don't believe it has great integration with GitHub (I did not see any
mention in infra) and when I used it at RedHat it was really heavy and
clunky, and designed to manage all the software under some enterprise
organization. The only thing I think it has going for it is that it's
opensource unlike JIRA and GitHub and if you manage it, it will work.

--brennan

On Tue, Jan 14, 2020, 4:25 PM Nathan Hartman 
wrote:

> On Tue, Jan 14, 2020 at 7:17 PM Gregory Nutt  wrote:
> > The implication is the you would be opposed to Bugzilla. Bugzilla is
> > more primitive but is has the advantage of being lightweight and fast.
> > Most pull-back from Jira would be, I think, because it is a heavyweight
> > solution (but also does much more than just track issues).
>
> I am not opposed but I don't know much about Bugzilla. I've never used
> it personally. So I can't argue in favor or against it. If others
> support it, then I would be neutral on that.
>
> Nathan
>

Re: Bug Tracking

[Nathan Hartman]

On Tue, Jan 14, 2020 at 7:17 PM Gregory Nutt  wrote:
> Most pull-back from Jira would be, I think, because it is a heavyweight
> solution (but also does much more than just track issues).

When you say that Jira is a heavyweight solution, do you mean in terms
of the infrastructure required to run it, or in terms of how easy/hard
it is to use?

Nathan

Re: Bug Tracking

[Nathan Hartman]

On Tue, Jan 14, 2020 at 7:17 PM Gregory Nutt  wrote:
> The implication is the you would be opposed to Bugzilla. Bugzilla is
> more primitive but is has the advantage of being lightweight and fast.
> Most pull-back from Jira would be, I think, because it is a heavyweight
> solution (but also does much more than just track issues).

I am not opposed but I don't know much about Bugzilla. I've never used
it personally. So I can't argue in favor or against it. If others
support it, then I would be neutral on that.

Nathan

Re: Bug Tracking

[Gregory Nutt]

I am fine with either of the following two options (not in any order of
preference):

(1) GitHub issues with separate issues for each repository, i.e., issues
with "apps" are reported against "apps," *not* against NuttX.
 Pros: Convenience and widespread familiarity across the FOSS world.
 Cons: Excludes those who can not access GitHub. Does not support an
issue that affects both repositories. Not running on ASF infrastructure.

(2) Jira, with issues correctly tagged as affecting the OS, or affecting
apps, or affecting both.
 Pros: Running on ASF infrastructure. Inclusiveness for those who cannot
use GitHub.
 Cons: Loss of the conveniences provided by the GitHub option.

Of course, I am open to consider other suggestions that might be offered.
:-)


The implication is the you would be opposed to Bugzilla. Bugzilla is 
more primitive but is has the advantage of being lightweight and fast.  
Most pull-back from Jira would be, I think, because it is a heavyweight 
solution (but also does much more than just track issues).

Re: Bug Tracking

[Nathan Hartman]

On Tue, Jan 14, 2020 at 6:32 PM Justin Mclean 
wrote:

> Hi,
>
> Part of the issues to consider is that If you use GitHub issues, having
> multiple repos you may need to enable issues in multiple places. This means
> more to manage and track. Having all issues for multiple repos on a single
> github repo also has issues.
>
> I don’t think there’s an ideal solution here, I’ve used both JIRA and
> GitHub issues in the past and they both have their advantages and
> disadvantages. The PPMC needs to come up with a solution that everyone is
> willing to work with, even if it is not everyone first choice. It might be
> a good idea if each of the 13 PPMC members express their opinion or someone
> listed the possible options and people indicated their choice. A valid
> opinion would be "I’m fine with any solution”.


I am fine with either of the following two options (not in any order of
preference):

(1) GitHub issues with separate issues for each repository, i.e., issues
with "apps" are reported against "apps," *not* against NuttX.
Pros: Convenience and widespread familiarity across the FOSS world.
Cons: Excludes those who can not access GitHub. Does not support an
issue that affects both repositories. Not running on ASF infrastructure.

(2) Jira, with issues correctly tagged as affecting the OS, or affecting
apps, or affecting both.
Pros: Running on ASF infrastructure. Inclusiveness for those who cannot
use GitHub.
Cons: Loss of the conveniences provided by the GitHub option.

Of course, I am open to consider other suggestions that might be offered.
:-)

Cheers,
Nathan

Re: Apache Code Relese (Was Re: Side-effects of removing (void))

[Gregory Nutt]

Well, we still don't have a clean build yet 8(   I got to configuration 
342 out of the 420 then it failed on a THTTP + binfs build what has 
worked for years (olimex-lpc1766stk:thttpd-binfs). No idea while.  I 
will look into that tomorrow.


Greg

Re: Bug Tracking

[Gregory Nutt]

Part of the issues to consider is that If you use GitHub issues, having 
multiple repos you may need to enable issues in multiple places. This means 
more to manage and track. Having all issues for multiple repos on a single 
github repo also has issues.

I don’t think there’s an ideal solution here, I’ve used both JIRA and GitHub issues 
in the past and they both have their advantages and disadvantages. The PPMC needs to 
come up with a solution that everyone is willing to work with, even if it is not 
everyone first choice. It might be a good idea if each of the 13 PPMC members 
express their opinion or someone listed the possible options and people indicated 
their choice. A valid opinion would be "I’m fine with any solution”.


Okay... here is my opinion:

1. I don't care if we use Jira, Bugzilla, or Github Issues.  You pick.  
I will support the PPMC's preference with a +1 vote.


2. There is only one option that I want to avoid.  If we use Github 
issues, I would want issues to be enabled in all repositories.  The only 
position I have heard that I am opposed to is enabling issues only on 
the OS repository then reporting all issues against the OS.  I am very 
STRONGLY opposed to dumping all issues on the OS and that would get a -1 
vote from me.


The recent discussion about security issues is a case in point. That is, 
again, a pre-Apache version of a low-effort, application in the apps/ 
directory... one of those quick, afternoon developments.  It would be 
offensive to report that security issue against the OS which has years 
of effort is unrelated to the security issue.  The OS is not involved 
and is the wrong place to report that error.  It would improperly 
reflect on the OS.  It should be reported against the applications as it 
was in the Bitbucket apps/ Issues.  That is correct.  It would be very 
wrong to report it against the OS.


Greg

Re: Apache Code Relese (Was Re: Side-effects of removing (void))

[Gregory Nutt]

Yes, it's great that we develop a tool to generate all possible
combination of affected options smartly.


It would be difficult to cover them all due to things like mutually 
exclusive "choice" and dependencies.  But if we could generate a tool 
that generated all possible configurations (assuming for a single 
board), then that could be very valuable.



Like Nanthan suggestion, we can create a special config to enable all
non-execlusive options, actually kconfig support --allyesconfig to
simplify this task.


I am not sure if that is useful or not.  Certainly not for bool settings 
whose default is already "yes

Re: Bug Tracking

[Justin Mclean]

Hi,

Part of the issues to consider is that If you use GitHub issues, having 
multiple repos you may need to enable issues in multiple places. This means 
more to manage and track. Having all issues for multiple repos on a single 
github repo also has issues.

I don’t think there’s an ideal solution here, I’ve used both JIRA and GitHub 
issues in the past and they both have their advantages and disadvantages. The 
PPMC needs to come up with a solution that everyone is willing to work with, 
even if it is not everyone first choice. It might be a good idea if each of the 
13 PPMC members express their opinion or someone listed the possible options 
and people indicated their choice. A valid opinion would be "I’m fine with any 
solution”.

Thanks,
Justin

Re: Apache Code Relese (Was Re: Side-effects of removing (void))

[Xiang Xiao]

On Wed, Jan 15, 2020 at 3:01 AM Gregory Nutt  wrote:
>
>
> > Haitao is preparing the jenkins job to run all possible config, but
> > the config number is huge, we need to donate several powerful severs
> > to ensure the precheck can finish in half hour.
>
> I am repeating myself, but it is worth remembering.
>
> There might not be any configuration in the repository that builds the
> code that is changed by a PR!  The code could be totally broken and
> could fail the first time you compile it, but if there is no
> configuration in the repository that has the configuration settings
> needed to build all options for the changed code, you will never know it.
>
> It is for this reason that have been arguing that we need a smarter test
> than just building a set of configurations.  The smaller the set the
> more likely that they will not build the affected code at all!   Then
> the build test is completely useless.
>

Yes, it's great that we develop a tool to generate all possible
combination of affected options smartly.

> I very typical example is when someone develops a new driver for some
> "FooBar" hardware.  It is enabled by CONFIG_DRIVER_FOOBAR. But there is
> no defconfig file under boards that includes CONFIG_DRIVER_FOOBAR=y.  As
> a result, any kind of canned build test is a waste of time and will not
> prove or disprove the syntactic correctness of the file -- since it
> never builds it.
>

Like Nanthan suggestion, we can create a special config to enable all
non-execlusive options, actually kconfig support --allyesconfig to
simplify this task.

> I have suggested that we ask the contributor to provide a list of every
> configuration option that needs to be set/unset to verify all
> combinations of the changed code.  Then we use those configuration
> options to select all relevant configurations.
>
> Perhaps we could grep the modified files to get those options?
>
> In the case that there is no configuration in the repository that select
> those configuration options, we would need to ask the contributor to
> provide a test configuration.
>
> Anything that is random, hit or miss would be, most likely, a waste of time.
>
> Greg
>
>
>
>

Bug Tracking

[Gregory Nutt]

We started a discussion about bug tracking and never really came to a 
consensus.  I notice that the ASF also provides Bugzilla: 
https://bz.apache.org/bugzilla/


That is an older, simpler tool than Jira but probably also should be 
considered.


I haven't used Bugzilla for years and I can't really remember much about 
it other than it does track bugs.  I don't have any other strong 
impressions.  It is neither slow nor is it complicated.


Greg

Towards making your first Apache release

[Justin Mclean]

Hi,

If the PPMC want to get started making a release I suggest they do the 
following:
1. Someone puts up their hand up to be the release manager. Do we have any 
takers?
2. Add LICENSE and NOTICE and DISCLAIMER to the repo. COPYING may need to be 
modified/removed.
3. Decide on approach to take with the disclaimer.
4. Decide on what approach to take with the file headers.
5. Check that licensing (including dependancies) is compatible with ALv2.
6. Document how to create a source release package.
7. Create release candidate and vote on release.
8. If vote fails report 7 as many times as needed.
9. Put the release up for IPMC vote.
10. If that vote fail got back to 7.
11. Ship it!

This can occur in parallel with sorting out the build testing infrastructure. 

I can help and provide advice along the way. I've been a release manager for 
many releases and have reviewed 100’s of release at the ASF.

Thanks,
Justin

Re: Apache Code Relese (Was Re: Side-effects of removing (void))

[Justin Mclean]

Hi,

> We need get the manager approve before we can send the official announcement. 

Also this is something the whole PPMC need to be involved in and make a 
decision on before any announcement is made.

I’m a little unclear what context you mean as an announcement there, incubating 
project need to take care with publicity, please see [1], note that "No formal 
press releases or announcements of any kind are allowed to be disseminated on 
any newswire service during the Incubation process."

Thanks,
Justin

1. https://incubator.apache.org/guides/publicity.html

Re: Apache Code Relese (Was Re: Side-effects of removing (void))

[Justin Mclean]

Hi,

> This just our internal test,and share in Wechat, not the final report.

What is this conversation happening in WeChat? It needs to be on the mailing 
list. It’s fine to use WeCat for casual conversation but anything that affects 
the project needs to be brought back to this mailing list.

> We need get the manager approve before we can send the official
> announcement. Also why I should report our internal conversation
> publicly? 

All conversations about the project need to be open and transparent and occur 
in public. They need to be in a place that is searchable and archivable. I 
can't imagine any reason for a conversation like this would need to be private, 
but I don’t know the exact details. Other PPMC members and your mentors need to 
be aware of what is going on and if they are aware they can help. For instance, 
have you involved Infra in these dicusssions?

Let say  for some reason, it didn’t get approval from your manager if that 
conversation was  public, another individual (or more than one) may be able to 
step and help out and donate the needed resources instead. Or it might even be 
possible that there's no need to donate anything and Infra can provide the 
resources you need.

Thanks,
Justin

Re: Apache Code Relese (Was Re: Side-effects of removing (void))

[Xiang Xiao]

On Wed, Jan 15, 2020 at 5:54 AM Justin Mclean  wrote:
>
> Hi,
>
> > The report from Haitao show that all arm 400 config can build within
> > 94min with his machine
>
> What report? Where can I find this?
>

This just our internal test,and share in Wechat, not the final report.
I shared this information just let the community know how much
workload we need to support the full build.

> > We are discussing internally to donate several build machines to
> > ensure all build could finish within half hour.
>
> Why is this conversation not happing on this list?
>

We need get the manager approve before we can send the official
announcement. Also why I should report our internal conversation
publicly? I think that we share the final information(e.g. we donate
two servers to ASF) is enough, is it right?

> Thanks,
> Justin

Re: Apache Code Relese (Was Re: Side-effects of removing (void))

[Justin Mclean]

Hi,

> The report from Haitao show that all arm 400 config can build within
> 94min with his machine

What report? Where can I find this?

> We are discussing internally to donate several build machines to
> ensure all build could finish within half hour.

Why is this conversation not happing on this list?

Thanks,
Justin

Re: Apache Code Relese (Was Re: Side-effects of removing (void))

[Justin Mclean]

Hi,

> Speaking of LINT, another avenue might be static analysis, which finds all
> kinds of common errors. That is imperfect and comes with false negatives
> but is useful nonetheless.

Apache projects have access to this [1]. I used it in the past to good effect. 

It does support C projects. e.g [2] for all Apache projects see [3].

Thanks,
Justin

1. https://cwiki.apache.org/confluence/display/INFRA/SonarQube+Analysis
2. https://sonarcloud.io/dashboard?id=milagro
3. https://sonarcloud.io/organizations/apache/projects

Re: Apache Code Relese (Was Re: Side-effects of removing (void))

[Xiang Xiao]

On Wed, Jan 15, 2020 at 2:21 AM Gregory Nutt  wrote:
>
> Hi, Xiang,
> > Since NuttX use Kconfig system, the simple pull/apply/compile cycle
> > isn't enough to catch all possible error. Actually, all my commits
> > pass our local automation build(four config: sim, armv7-m, armv8-m and
> > armv7-a) before PR sent out.
>
> It is hard to imagine how they could have passed with typos in errno
> values for example.  Perhaps your configurations just did not build the
> files that generated the compilation errors.  We really have to build
> many, many configurations to have confidence that the change does not
> break anything.

Yes, that's typo errors just happened when the write buffer isn't
enable, all our config enable the write buffer unfortunately.

>
> We have an obligation to assure our users the EVERY configuration that
> is included in the release builds correctly.  Not some of them, not most
> of them, not a representative set of them, but ALL of them.
>
> I had a similar issues one an nxstyle commit recently.  Nxstyle built
> fine under Cygwin, but failed to build under Linux.  It needed to
> include stdint.h.  That inclusion was not necessary under Cygwin perhaps
> because stdint.h was included indirectly through some other header file.
>
> > Haitao is preparing the jenkins job to run all possible config, but
> > the config number is huge, we need to donate several powerful severs
> > to ensure the precheck can finish in half hour.
>
> If we use a smaller set to qualify a PR for merging, then I think we
> would be okay.  We could then run the entire set of configurations
> asynchronously to assure that all configurations build.
>
> Of course, there will be some errors:  Some cases where a PR builds in
> the smaller set of configurations, but not for the entire set.  That
> case would be rarer and should not affect so many users.  Any problems
> found with the entire set build could be fixed by the next day.  That
> seems like a reasonable compromise.

The report from Haitao show that all arm 400 config can build within
94min with his machine, so I think it is reasonable to achieve half
hour goal by:
1.Enable more optimaition(e.g. ccache, ramdisk...)
2.Use more powerful machine(e.g. big memory, more cpu core and fast SSD)
And we can use one Linux machine build all arm config, and anthor
Windows machine build the rest config with cygwin, msys, wsl.
We are discussing internally to donate several build machines to
ensure all build could finish within half hour.

>
> Greg

Re: Apache Code Relese (Was Re: Side-effects of removing (void))

[Nathan Hartman]

On Tue, Jan 14, 2020 at 2:01 PM Gregory Nutt  wrote:

>
> > Haitao is preparing the jenkins job to run all possible config, but
> > the config number is huge, we need to donate several powerful severs
> > to ensure the precheck can finish in half hour.
>
> I am repeating myself, but it is worth remembering.
>
> There might not be any configuration in the repository that builds the
> code that is changed by a PR!  The code could be totally broken and
> could fail the first time you compile it, but if there is no
> configuration in the repository that has the configuration settings
> needed to build all options for the changed code, you will never know it.
>
> It is for this reason that have been arguing that we need a smarter test
> than just building a set of configurations.  The smaller the set the
> more likely that they will not build the affected code at all!   Then
> the build test is completely useless.
>
> I very typical example is when someone develops a new driver for some
> "FooBar" hardware.  It is enabled by CONFIG_DRIVER_FOOBAR. But there is
> no defconfig file under boards that includes CONFIG_DRIVER_FOOBAR=y.  As
> a result, any kind of canned build test is a waste of time and will not
> prove or disprove the syntactic correctness of the file -- since it
> never builds it.
>
> I have suggested that we ask the contributor to provide a list of every
> configuration option that needs to be set/unset to verify all
> combinations of the changed code.  Then we use those configuration
> options to select all relevant configurations.
>
> Perhaps we could grep the modified files to get those options?
>
> In the case that there is no configuration in the repository that select
> those configuration options, we would need to ask the contributor to
> provide a test configuration.
>
> Anything that is random, hit or miss would be, most likely, a waste of
> time.


I don't know how they do it now, but back in the day I remember that the
FreeBSD project had a configuration that is not valid for running, but
which builds ALL options (including, I presume, options that should be
mutually exclusive), to catch build errors. I think it was called something
with LINT in the name. Maybe that's one of the avenues we could consider,
in parallel with other build tests of valid configurations.

Speaking of LINT, another avenue might be static analysis, which finds all
kinds of common errors. That is imperfect and comes with false negatives
but is useful nonetheless.

Nathan

Re: Apache Code Relese (Was Re: Side-effects of removing (void))

[Gregory Nutt]

Haitao is preparing the jenkins job to run all possible config, but
the config number is huge, we need to donate several powerful severs
to ensure the precheck can finish in half hour.


I am repeating myself, but it is worth remembering.

There might not be any configuration in the repository that builds the 
code that is changed by a PR!  The code could be totally broken and 
could fail the first time you compile it, but if there is no 
configuration in the repository that has the configuration settings 
needed to build all options for the changed code, you will never know it.


It is for this reason that have been arguing that we need a smarter test 
than just building a set of configurations.  The smaller the set the 
more likely that they will not build the affected code at all!   Then 
the build test is completely useless.


I very typical example is when someone develops a new driver for some 
"FooBar" hardware.  It is enabled by CONFIG_DRIVER_FOOBAR. But there is 
no defconfig file under boards that includes CONFIG_DRIVER_FOOBAR=y.  As 
a result, any kind of canned build test is a waste of time and will not 
prove or disprove the syntactic correctness of the file -- since it 
never builds it.


I have suggested that we ask the contributor to provide a list of every 
configuration option that needs to be set/unset to verify all 
combinations of the changed code.  Then we use those configuration 
options to select all relevant configurations.


Perhaps we could grep the modified files to get those options?

In the case that there is no configuration in the repository that select 
those configuration options, we would need to ask the contributor to 
provide a test configuration.


Anything that is random, hit or miss would be, most likely, a waste of time.

Greg

Re: [nuttx][PATCH] Added Support for RTC & IPV6 on RX65N

[David Alessio]

Anjana,

Please remove the Disclaimer from your email, it's incorrect -- you're
sending files containing source code to an open-source project and claiming
confidentiality and intended use by an individual...

Regards,
-david

On Mon, Jan 13, 2020 at 10:02 PM Anjana 
wrote:

> Hi All,
>
> We have uploaded patch for arch/renesas & boards/.
>
> The patch is created for the code version dated 08th Jan 2020 (Downloaded
> on 08th Jan 2020).
>
> This patch adds support for the following :
>
>
>1. Added Support for RTC driver in RX65N
>2. Added support for IPV6.
>
>
> Regards,
>
> Anjana
> --
> *Disclaimer: This email and any files transmitted with it are confidential
> and intended solely for the use of the individual or entity to whom they
> are addressed. If you are not the intended recipient of this message , or
> if this message has been addressed to you in error, please immediately
> alert the sender by reply email and then delete this message and any
> attachments. If you are not the intended recipient, you are hereby notified
> that any use, dissemination, copying, or storage of this message or its
> attachments is strictly prohibited. Email transmission cannot be guaranteed
> to be secure or error-free, as information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or contain viruses. The sender,
> therefore, does not accept liability for any errors, omissions or
> contaminations in the contents of this message which might have occurred as
> a result of email transmission. If verification is required, please request
> for a hard-copy version. *
> --
>

Re: Apache Code Relese (Was Re: Side-effects of removing (void))

[Gregory Nutt]

Hi, Xiang,

Since NuttX use Kconfig system, the simple pull/apply/compile cycle
isn't enough to catch all possible error. Actually, all my commits
pass our local automation build(four config: sim, armv7-m, armv8-m and
armv7-a) before PR sent out.


It is hard to imagine how they could have passed with typos in errno 
values for example.  Perhaps your configurations just did not build the 
files that generated the compilation errors.  We really have to build 
many, many configurations to have confidence that the change does not 
break anything.


We have an obligation to assure our users the EVERY configuration that 
is included in the release builds correctly.  Not some of them, not most 
of them, not a representative set of them, but ALL of them.


I had a similar issues one an nxstyle commit recently.  Nxstyle built 
fine under Cygwin, but failed to build under Linux.  It needed to 
include stdint.h.  That inclusion was not necessary under Cygwin perhaps 
because stdint.h was included indirectly through some other header file.



Haitao is preparing the jenkins job to run all possible config, but
the config number is huge, we need to donate several powerful severs
to ensure the precheck can finish in half hour.


If we use a smaller set to qualify a PR for merging, then I think we 
would be okay.  We could then run the entire set of configurations 
asynchronously to assure that all configurations build.


Of course, there will be some errors:  Some cases where a PR builds in 
the smaller set of configurations, but not for the entire set.  That 
case would be rarer and should not affect so many users.  Any problems 
found with the entire set build could be fixed by the next day.  That 
seems like a reasonable compromise.


Greg

Re: Apache Code Relese (Was Re: Side-effects of removing (void))

[Gregory Nutt]

How about just collecting a bunch of commonly used configurations from
users? Maybe using the example configs that are in the repo now, but
adapting them to be run on the version that is being run in Jenkins...?
That is not perfect, but even having 10-20 example configs would be better
than 1. :)


That would reduce the time but would not find all of the errors. 
Sometimes I build 300 or so configurations before I see the first failure.


We need to build more configurations to catch more problems, not fewer.

I think fewer would be okay for a pre-commit check, provided that the 
entire set were built at least once per day.  I have no idea how you 
would pick a representative subset.  Maybe it would be best to select 
them randomly on each PR?

Re: Apache Code Relese (Was Re: Side-effects of removing (void))

[Adam Feuer]

Xiang,

How about just collecting a bunch of commonly used configurations from
users? Maybe using the example configs that are in the repo now, but
adapting them to be run on the version that is being run in Jenkins...?
That is not perfect, but even having 10-20 example configs would be better
than 1. :)

cheers
adam

On Tue, Jan 14, 2020 at 9:22 AM Xiang Xiao 
wrote:

> Since NuttX use Kconfig system, the simple pull/apply/compile cycle
> isn't enough to catch all possible error. Actually, all my commits
> pass our local automation build(four config: sim, armv7-m, armv8-m and
> armv7-a) before PR sent out.
> Haitao is preparing the jenkins job to run all possible config, but
> the config number is huge, we need to donate several powerful severs
> to ensure the precheck can finish in half hour.
>
> Thanks
> Xiang
>
> On Tue, Jan 14, 2020 at 10:37 PM Alin Jerpelea  wrote:
> >
> > Just a small checklist before pushing.!
> >
> > 1  *pull master*
> > 2. add your patch(es)
> > 3.* compile*
> > 4  make distclean
> > 5.* PUSH*
> >
> > Let's  hope that we avoid having it broken again
> >
> > On our side as commiters, before the automation is ready, we should
> > cherry-pick and build before pressing the merge button
> > Can we all do that ?
> >
> > //Alin
> >
> >
> > On Tue, Jan 14, 2020, 15:15 David Sidrane 
> wrote:
> >
> > > The NuttX project is still misusing the tools.
> > > It is not the PR. It is the process (or lack of one)
> > >
> > > To solve this problem:
> > >
> > > Build the PR on top of master BEFORE merging.
> > > Do not MERGE until PR on master builds.
> > >
> > > David
> > >
> > > -Original Message-
> > > From: Gregory Nutt [mailto:spudan...@gmail.com]
> > > Sent: Monday, January 13, 2020 6:00 PM
> > > To: dev@nuttx.apache.org
> > > Subject: Re: Apache Code Relese (Was Re: Side-effects of removing
> (void))
> > >
> > >
> > > > The point I'd like to make, is that I'd much rather the whole world
> stop
> > > > turning, nothing get merged into master until we sort out the
> process;
> > > > rather than allow anything to break master.  I'd like for us to
> adopt a
> > > > philosophy that "Nothing is worse than breaking Master."  Now, that's
> > > just
> > > > me, I welcome counterarguments (and even flames).
> > >
> > > Nothing in the process is particularly different at present than in the
> > > past.  Several unverified PRs came in close together in time.  Since
> > > each broke the build and were separated over time, the build remained
> > > broken for a couple weeks or more.
> > >
> > > There is nothing significantly different in the process from when when
> > > patches were added in the same manner.  Users are simply not acting
> > > responsibly right now and are not verifying the changes before
> > > committing them (it appears, in cases, that they are not even compiling
> > > them!).  That behavior has to stop.
> > >
> > > We were just luckier in the past and I think people were more careful
> > > when they had to work up patches vs. just pushing a button to create a
> > > PR.  The ease of creating PRs with one finger leads to sloppiness.
> > >
> > > Greg
> > >
>


-- 
Adam Feuer 

Re: Side-effects of removing (void)

[Xiang Xiao]

On Mon, Jan 13, 2020 at 8:32 AM Gregory Nutt  wrote:
>
>
> >
> >> So I guess our choices are:
> >>
> >> 1. Reinstate (void) only where the warning occurs.
> >>
> >> 2. Reinstate (void) everywhere return values aren't checked. What a
> >> nightmare.
> >>
> >> 3. Change defines such as the above to static inline functions.
> >> Disadvantage: The inline keyword is not in the C89 standard.
> >
> > I have ran the build tests and do not know of any other cases like
> > this.  Certainly, a few more might show up but it is not an endemic
> > problem at the moment.
> >
> > At its worst, it is only a warning.
>
> The real problem here is not really that we may (or may not have) opened
> up a bunch of new warnings.  The issue here is that our QA process
> sucks.  We make enormous changes like this and commit it to master
> without so little as verifying that the code compiles and or that it
> builds without introducing new warnings.  The code is just changed and
> "thrown over the fence."
>
> This is total unprofessional and must come to a stop.  The way to bring
> this to a stop is to complete the workflow definition and the
> implementation of some nightly builld-everything step that has to happen
> before any PR is committed.  The fix is to improve our QA processes so
> that this cannot happen.
>
> But we have, apparently, lost interest in the workflow. Apparently,
> Haitao Liu is working on something, but that is a black box.  We have no
> visibility of what is happening, what is being done in detail, when it
> will be rolled out, or how it integrates with the unfinished workflow.
>

Haitao is trying to create the jenkins job which will run all builtin
config: any build error either get fixed or config should be remove
from repo.
The integration is simple: each commit MUST pass the build check
before it can merge into mainline.

> Greg
>
>
>

Re: Apache Code Relese (Was Re: Side-effects of removing (void))

[Xiang Xiao]

Since NuttX use Kconfig system, the simple pull/apply/compile cycle
isn't enough to catch all possible error. Actually, all my commits
pass our local automation build(four config: sim, armv7-m, armv8-m and
armv7-a) before PR sent out.
Haitao is preparing the jenkins job to run all possible config, but
the config number is huge, we need to donate several powerful severs
to ensure the precheck can finish in half hour.

Thanks
Xiang

On Tue, Jan 14, 2020 at 10:37 PM Alin Jerpelea  wrote:
>
> Just a small checklist before pushing.!
>
> 1  *pull master*
> 2. add your patch(es)
> 3.* compile*
> 4  make distclean
> 5.* PUSH*
>
> Let's  hope that we avoid having it broken again
>
> On our side as commiters, before the automation is ready, we should
> cherry-pick and build before pressing the merge button
> Can we all do that ?
>
> //Alin
>
>
> On Tue, Jan 14, 2020, 15:15 David Sidrane  wrote:
>
> > The NuttX project is still misusing the tools.
> > It is not the PR. It is the process (or lack of one)
> >
> > To solve this problem:
> >
> > Build the PR on top of master BEFORE merging.
> > Do not MERGE until PR on master builds.
> >
> > David
> >
> > -Original Message-
> > From: Gregory Nutt [mailto:spudan...@gmail.com]
> > Sent: Monday, January 13, 2020 6:00 PM
> > To: dev@nuttx.apache.org
> > Subject: Re: Apache Code Relese (Was Re: Side-effects of removing (void))
> >
> >
> > > The point I'd like to make, is that I'd much rather the whole world stop
> > > turning, nothing get merged into master until we sort out the process;
> > > rather than allow anything to break master.  I'd like for us to adopt a
> > > philosophy that "Nothing is worse than breaking Master."  Now, that's
> > just
> > > me, I welcome counterarguments (and even flames).
> >
> > Nothing in the process is particularly different at present than in the
> > past.  Several unverified PRs came in close together in time.  Since
> > each broke the build and were separated over time, the build remained
> > broken for a couple weeks or more.
> >
> > There is nothing significantly different in the process from when when
> > patches were added in the same manner.  Users are simply not acting
> > responsibly right now and are not verifying the changes before
> > committing them (it appears, in cases, that they are not even compiling
> > them!).  That behavior has to stop.
> >
> > We were just luckier in the past and I think people were more careful
> > when they had to work up patches vs. just pushing a button to create a
> > PR.  The ease of creating PRs with one finger leads to sloppiness.
> >
> > Greg
> >

Re: Apache Code Relese (Was Re: Side-effects of removing (void))

[Alin Jerpelea]

Just a small checklist before pushing.!

1  *pull master*
2. add your patch(es)
3.* compile*
4  make distclean
5.* PUSH*

Let's  hope that we avoid having it broken again

On our side as commiters, before the automation is ready, we should
cherry-pick and build before pressing the merge button
Can we all do that ?

//Alin


On Tue, Jan 14, 2020, 15:15 David Sidrane  wrote:

> The NuttX project is still misusing the tools.
> It is not the PR. It is the process (or lack of one)
>
> To solve this problem:
>
> Build the PR on top of master BEFORE merging.
> Do not MERGE until PR on master builds.
>
> David
>
> -Original Message-
> From: Gregory Nutt [mailto:spudan...@gmail.com]
> Sent: Monday, January 13, 2020 6:00 PM
> To: dev@nuttx.apache.org
> Subject: Re: Apache Code Relese (Was Re: Side-effects of removing (void))
>
>
> > The point I'd like to make, is that I'd much rather the whole world stop
> > turning, nothing get merged into master until we sort out the process;
> > rather than allow anything to break master.  I'd like for us to adopt a
> > philosophy that "Nothing is worse than breaking Master."  Now, that's
> just
> > me, I welcome counterarguments (and even flames).
>
> Nothing in the process is particularly different at present than in the
> past.  Several unverified PRs came in close together in time.  Since
> each broke the build and were separated over time, the build remained
> broken for a couple weeks or more.
>
> There is nothing significantly different in the process from when when
> patches were added in the same manner.  Users are simply not acting
> responsibly right now and are not verifying the changes before
> committing them (it appears, in cases, that they are not even compiling
> them!).  That behavior has to stop.
>
> We were just luckier in the past and I think people were more careful
> when they had to work up patches vs. just pushing a button to create a
> PR.  The ease of creating PRs with one finger leads to sloppiness.
>
> Greg
>

RE: Apache Code Relese (Was Re: Side-effects of removing (void))

[David Sidrane]

The NuttX project is still misusing the tools.
It is not the PR. It is the process (or lack of one)

To solve this problem:

Build the PR on top of master BEFORE merging.
Do not MERGE until PR on master builds.

David

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Monday, January 13, 2020 6:00 PM
To: dev@nuttx.apache.org
Subject: Re: Apache Code Relese (Was Re: Side-effects of removing (void))


> The point I'd like to make, is that I'd much rather the whole world stop
> turning, nothing get merged into master until we sort out the process;
> rather than allow anything to break master.  I'd like for us to adopt a
> philosophy that "Nothing is worse than breaking Master."  Now, that's just
> me, I welcome counterarguments (and even flames).

Nothing in the process is particularly different at present than in the
past.  Several unverified PRs came in close together in time.  Since
each broke the build and were separated over time, the build remained
broken for a couple weeks or more.

There is nothing significantly different in the process from when when
patches were added in the same manner.  Users are simply not acting
responsibly right now and are not verifying the changes before
committing them (it appears, in cases, that they are not even compiling
them!).  That behavior has to stop.

We were just luckier in the past and I think people were more careful
when they had to work up patches vs. just pushing a button to create a
PR.  The ease of creating PRs with one finger leads to sloppiness.

Greg

Re: [nuttx][PATCH] Added Support for RTC & IPV6 on RX65N

[Alan Carvalho de Assis]

Hi Anjana,

Your patch was generated incorrectly, it doesn't apply.

You can test it yourself to confirm it doesn't work:

Clone a pristine incubator-nuttx from github, enter inside it and run:

$ patch -p1 --dry-run < /tmp/RX65N_arch.txt

You will see many Hunk #xxx FAILED ...:

172 out of 172 hunks FAILED
The next patch would create the file arch/renesas/src/.gitignore

Please fork the apache incubator-nuttx in github and work with it,
then you can submit a PR (Pull Request) from github directly if you
prefer.

I noticed you used "diff -Naur" to compare two different repositories,
however I noticed an interesting thing:

diff -Naur nuttx-8.2_apache_202001101453/arch/renesas/include/rx65n/iodefine.h
incubator-nuttx-master/arch/renesas/include/rx65n/iodefine.h
--- nuttx-8.2_apache_202001101453/arch/renesas/include/rx65n/iodefine.h
2019-12-20 10:27:18.0 +0530
+++ incubator-nuttx-master/arch/renesas/include/rx65n/iodefine.h
 2020-01-10 02:52:48.0 +0530
@@ -907,61 +907,20 @@
 #define  _CLR( x )  __CLR( x )
 #define   CLR( x , y )  _CLR( _ ## x ## _ ## y )

-#define BSC (*(volatile struct st_bsc  *)0x81300)
-#define CAC (*(volatile struct st_cac  *)0x8b000)
-#define CAN0(*(volatile struct st_can  *)0x90200)
-#define CAN1(*(volatile struct st_can  *)0x91200)
-#define CMT (*(volatile struct st_cmt  *)0x88000)
+#define BSC (*(volatile struct st_bsc  *)0x81300)
+#define CAC (*(volatile struct st_cac  *)0x8b000)
+#define CMT (*(volatile struct st_cmt  *)0x88000)

But, if you loop the apache incubator-nuttx file
arch/renesas/include/rx65n/iodefine.h at github you will see:

#define BSC (*(volatile struct st_bsc  *)0x81300)
#define CAC (*(volatile struct st_cac  *)0x8b000)
#define CMT (*(volatile struct st_cmt  *)0x88000)
#define CMT0(*(volatile struct st_cmt0 *)0x88002)
#define CMT1(*(volatile struct st_cmt0 *)0x88008)
#define CMT2(*(volatile struct st_cmt0 *)0x88012)
#define CMT3(*(volatile struct st_cmt0 *)0x88018)

Note that after BSC there are too much space characters that don't
exist at your incubator-nuttx-master, maybe because you or someone
else already modified it.

Also note that the current file in github already has the definitions
sequence your patch was trying to create: (BSC, CAC, CMT, ...), but in
github it is incorrectly formatted (wrong spaces).

Please review everything carefully, run nxstyle and before submitting
a patch or PR verify if the generated diff files are correct.

BR,

Alan

On 1/14/20, Anjana  wrote:
> Hi All,
>
> We have uploaded patch for arch/renesas & boards/.
>
> The patch is created for the code version dated 08th Jan 2020 (Downloaded on
> 08th Jan 2020).
>
> This patch adds support for the following :
>
>
>   1.  Added Support for RTC driver in RX65N
>   2.  Added support for IPV6.
>
>
> Regards,
>
> Anjana
>
> 
> Disclaimer: This email and any files transmitted with it are confidential
> and intended solely for the use of the individual or entity to whom they are
> addressed. If you are not the intended recipient of this message , or if
> this message has been addressed to you in error, please immediately alert
> the sender by reply email and then delete this message and any attachments.
> If you are not the intended recipient, you are hereby notified that any use,
> dissemination, copying, or storage of this message or its attachments is
> strictly prohibited. Email transmission cannot be guaranteed to be secure or
> error-free, as information could be intercepted, corrupted, lost, destroyed,
> arrive late or incomplete, or contain viruses. The sender, therefore, does
> not accept liability for any errors, omissions or contaminations in the
> contents of this message which might have occurred as a result of email
> transmission. If verification is required, please request for a hard-copy
> version.
> 
>

RE: SMTP send mail example build failure

[Surya prakash Verma]

Hello All,

Please find Kconfig attachment which was missed in last mail.

Regards,
Surya

From: Surya prakash Verma [mailto:surya.prak...@tataelxsi.co.in.INVALID]
Sent: Tuesday, January 14, 2020 3:50 PM
To: dev@nuttx.apache.org
Subject: SMTP send mail example build failure

surya.prak...@tataelxsi.co.in.INVALID appears similar to someone who previously 
sent you email, but may not be that person. Learn why this could be a 
risk
Feedback

**This is an external email. Please check the sender’s full email address (not 
just the sender name) and exercise caution before you respond or click any 
embedded link/attachment.**

Hello All,

I am trying to build SMTP send mail example in NuttX 8.2 but getting compiler 
error as shown in attachment.


1.   Nuttx/configure->Application configure->Network Utilities->smtp

2.   Nuttx/configure->Application configure->example->send mail example

I have analyze error and observed that following configuration is not available 
for configuration.

CONFIG_EXAMPLES_SENDMAIL_RECIPIENT

CONFIG_EXAMPLES_SENDMAIL_IPADDR

CONFIG_EXAMPLES_SENDMAIL_DRIPADDR

CONFIG_EXAMPLES_SENDMAIL_NETMASK


I able to build by adding above configuration in apps/example/sendmail/Kconfig.

Modified Kconfig attached to this mail.

Did anyone face similar issue?

Thanks & Regards,
Surya







Disclaimer: This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you are not the intended recipient of this message , or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply email and then delete this message and any attachments. If you are not 
the intended recipient, you are hereby notified that any use, dissemination, 
copying, or storage of this message or its attachments is strictly prohibited. 
Email transmission cannot be guaranteed to be secure or error-free, as 
information could be intercepted, corrupted, lost, destroyed, arrive late or 
incomplete, or contain viruses. The sender, therefore, does not accept 
liability for any errors, omissions or contaminations in the contents of this 
message which might have occurred as a result of email transmission. If 
verification is required, please request for a hard-copy version.

#
# For a description of the syntax of this configuration file,
# see the file kconfig-language.txt in the NuttX tools repository.
#

config EXAMPLES_SENDMAIL
tristate "Sendmail example"
default n
---help---
Enable the sendmail example

if EXAMPLES_SENDMAIL

comment "IPv4 addresses"

config EXAMPLES_SENDMAIL_RECIPIENT
string "recipient address"
default "smtpnu...@example.com"

config EXAMPLES_SENDMAIL_IPADDR
hex "Sender IP address"
default 0x0a02

config EXAMPLES_SENDMAIL_DRIPADDR
hex "Default routing IP address"
default 0x0a01

config EXAMPLES_SENDMAIL_NETMASK
hex "Network Mask"
default 0xff00
endif # EXAMPLES_SENDMAIL

SMTP send mail example build failure

[Surya prakash Verma]

Hello All,

I am trying to build SMTP send mail example in NuttX 8.2 but getting compiler 
error as shown in attachment.


1.   Nuttx/configure->Application configure->Network Utilities->smtp

2.   Nuttx/configure->Application configure->example->send mail example

I have analyze error and observed that following configuration is not available 
for configuration.

CONFIG_EXAMPLES_SENDMAIL_RECIPIENT

CONFIG_EXAMPLES_SENDMAIL_IPADDR

CONFIG_EXAMPLES_SENDMAIL_DRIPADDR

CONFIG_EXAMPLES_SENDMAIL_NETMASK


I able to build by adding above configuration in apps/example/sendmail/Kconfig.

Modified Kconfig attached to this mail.

Did anyone face similar issue?

Thanks & Regards,
Surya







Disclaimer: This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you are not the intended recipient of this message , or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply email and then delete this message and any attachments. If you are not 
the intended recipient, you are hereby notified that any use, dissemination, 
copying, or storage of this message or its attachments is strictly prohibited. 
Email transmission cannot be guaranteed to be secure or error-free, as 
information could be intercepted, corrupted, lost, destroyed, arrive late or 
incomplete, or contain viruses. The sender, therefore, does not accept 
liability for any errors, omissions or contaminations in the contents of this 
message which might have occurred as a result of email transmission. If 
verification is required, please request for a hard-copy version.