[TEST] Joined

[david . sidrane]

 [TEST] Joined

Hi Group,

Is this thing live yet?

*David Sidrane*


*david.sidr...@gmail.com *

[Test] Joined

[david . sidrane]

 [Test] Joined

Is it alive?

David

RE: State of Bitbucket Repsitories

[David Sidrane]

The history will be intact no matter where it is. It will remain BSD until
the license changes. The change should be on a branch than a single commit.
Then it is a knife edge


-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Tuesday, December 10, 2019 7:44 AM
To: dev@nuttx.apache.org
Subject: Re: State of Bitbucket Repsitories


> just wanted to mention that there's also an automatic mirror on Gitlab at:
>
> https://gitlab.com/nuttx
>
There are dozens of mirrors of the NuttX Bitbucket repositories. Google
nuttx+mirror to see some of them.

An alternative disposition of the Bitbucket repositories might be to
make them manual mirrors of the Apache repositories.  AFAIK Bitbucket
does not support automated mirroring without a plug-in. But periodic
manually mirroring of the Apache repositories would help by assuring
that the Apache licensed code is pushed out to all NuttX mirrors as well.

I really don't know what is the best thing to do.  I think, ideally,
every user and every mirror should transition to the Apache code and
that there should not be some creeping unsupported BSD version.  If
someone decides to start supporting that stranded BSD version, then you
would have a BSD fork to deal with.  And trademark issues too.  There
cannot be a different OS called NuttX; there can be only one.  I just
cannot imagine a positive scenario with retaining an unsupported BSD
version of the RTOS.  I doubt the ASF would appreciate that either?

Still just brainstorming..

Workflow and Release strategy Proposal (Was RE: Project Emails)

[David Sidrane]

Precisely! We cut a branch as a Release Candidate. nuttx-MM.mm.rr-rcnn.
During the release cycle it can have back ports from master if a new feature
or bug fix is found it is added if deemed necessary to the release.

Workflow Proposal

I would ask that we adopt a workflow similar to PX4. [1] - see page 16.  Or
parts of it that work for us.

All development would be done on branches and only squashed atomic commits
would be done to master. (Think constantly working bisect on master)

Branches can be rebased - to reduce noise until review [1] see page 17

All commit message would have context. [1] - see page 16 (Think emails
subject tells me what happed, Filter out noise)

Regards,

David

[1] https://drive.google.com/open?id=1XHaNB3nTarjPL-CzO9CpZTl1NgX_kpqY


-Original Message-
From: spudaneco [mailto:spudan...@gmail.com]
Sent: Thursday, December 12, 2019 9:16 PM
To: dev@nuttx.apache.org
Subject: Re: Project Emails

Sent from Samsung tablet.
I think we should use release branches, unless we want to lock downthe repo
against all changes for the duration of the release prep ->release
candidate -> testing -> debating -> voting cycle, which couldtake a non
trivial amount of time.You could carry on business as usual on a temporary
branch, but that feels awkward.

RE: Project Emails

[David Sidrane]

How about sub modules? We atomically tag across both to keep the project in
proper synchronization.

David

-Original Message-
From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
Sent: Thursday, December 12, 2019 10:55 AM
To: dev@nuttx.apache.org
Subject: Re: Project Emails

On Thu, Dec 12, 2019 at 1:36 PM Gregory Nutt  wrote:
> A NuttX release consists of two tarballs nuttx/ and apps/. nuttx/ is the
> operating system proper; apps/ is a collection of applications that may
> or maynot be used with the operating system proper.  These applications
> including some key things and I think most people want to incorporate
> some subset of applications into their project.
>
> But since the applications are NOT part of the operating system they do
> need to remain separate.  I would argue against trying to merge
> application code into the operating system.  So I think we have to
> consider these two separate releases.  We historically release them
> together as a matched pair so that the use can be user that they
> interoperate properly.

+1 : I agree that nuttx and apps should stay separate.

That begs the question, are we going to have two separate Git
repositories? Because Git lacks support for multiple projects in one
repository. (There's nothing in Git that prevents you from trying, but
Git does not have the features that make the "monorepo"/"megarepo"
pattern work; e.g., it does not have sparse/partial working copies or
clones. Trying to combine nuttx and apps into one repository would
force everyone to clone a lot of content they may not need/want and
which may complicate building the RTOS with only their custom
applications.)

Nathan

Atomic git tagging (was RE: Project Emails)

[David Sidrane]

Greg,

I think the below steps will do a an atomic tag/branch (Branch protections
may be needed as well)

However, it exemplifies why Submodules are evil but useful.  A much simpler
approach is 2 folder is the same project - I am aware of ALL the arguments -
I agree with most of them but there are dependency on nuttx to apps from all
the defconfig files and nsh)

First question I would poll the community is: "How many of you do not use
the apps folder?"

--

NuttX  - is the Knot repo.
Apps is a sub module
Nuttx is a sub module

origin is the remote for NuttX, apps and nuttx

cd NuttX
git checkout master
git submodule sync --recursive && git submodule update --init --recursive

git checkout -b master_imx_network_fixes
cd nuttx
git checkout -b master_imx_network_fixes
cd ../apps
git checkout -b master_imx_network_fixes

cd ../nuttx
Do all your changes.
git add ...
git commit  ...
git push origin master_imx_network_fixes

cd ../apps
Do all your changes.
git add ...
git commit  ...
git push origin master_imx_network_fixes

cd .. (NuttX)
git add apps nuttx
git commit  ...

git tag -a nuttx-yada -m "my version 1.4"
git push origin nuttx-yada



David

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Thursday, December 12, 2019 7:05 PM
To: dev@nuttx.apache.org
Subject: Re: Project Emails


> How about sub modules? We atomically tag across both to keep the project
> in
> proper synchronization.

Some of these things are difficult to discuss at this point in time
because we not have enough Apache knowledge and experience. What I have
seen from following the release emails is the release will go through
several release candidates before before a final release is made.
Tagging releases as NuttX did in the past won't support that.  I believe
that you would have to use branches to support a series of release
candidates until the release is made (and perhaps even to support
further releases on the branch for bug fixes).

We can't really branch across sub-modules, can we?  I think we need to
know much more before we could take any clear position on this.

Greg

Point of order.

[david . sidrane]

 Point of order.

Recognizing that using the ASF mailing list is all new to some of us. I
would like to ask people to keep on topic in threads.

Greg raised the issue that the PPMC is not getting things done. I think it
is impossible to organize an effort without communication that is focused.
Please take the time to create new subject when branching off. It will help
us keep organized.

David

RE: [nuttx] Wiki Backup

[David Sidrane]

Looking good! Thank you Brennan!

-Original Message-
From: Brennan Ashton [mailto:bash...@brennanashton.com]
Sent: Tuesday, December 17, 2019 1:21 AM
To: dev@nuttx.apache.org
Subject: Re: [nuttx] Wiki Backup

Did another major round of updates.  I removed a few pages that just linked
to documentation pages that are already linked in the documentation
section.  We need to figure out what to do with what is in the
documentation section.
For PDFs and the like we can just attach them to the Documentation page and
then link them in the individual pages, but for the HTML if is a pain to
render the images as well.  I did a hack on the graphics one to replace the
image url, but it is not ideal.

There are also places like this where there is a link to download, and that
should be replaced with an attachment.
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629542

You can also use click Page Info to view all the external links for a
page.  For example there is a nuttx.org and three youtube links here
https://cwiki.apache.org/confluence/pages/viewinfo.action?pageId=139629542

Also about the long URLs Confluence also will generate the short link:

https://cwiki.apache.org/confluence/x/5pNSC


There are some pages where the import did some goofy things like putting
each line of a code block it its own block, but it is very rare and still
readable.

If others want to help review and fix formatting please do.

Justin, I'll ask INFRA if they can fix the space name.

Thanks,
Brennan
<https://cwiki.apache.org/confluence/x/5pNSC>

On Mon, Dec 16, 2019 at 12:12 PM David Sidrane 
wrote:

> Brennan,
>
> I bet it was grueling. Thank you again Brennan!
>
> David
> -Original Message-
> From: Brennan Ashton [mailto:bash...@brennanashton.com]
> Sent: Monday, December 16, 2019 7:50 AM
> To: dev@nuttx.apache.org
> Subject: Re: [nuttx] Wiki Backup
>
> Greg and David,
> The page names just need to finish getting updated, I did about 80% of
> them. I can finish that today, I just needed to go to sleep last night.
> Manually clicking through all the pages was grating on me.
>
> --Brennan
>
> On Mon, Dec 16, 2019, 3:21 AM David Sidrane 
> wrote:
>
> > Brennan,
> >
> > Thank you for your efforts!
> >
> > Justin: Is there an issue with adding all the PPMC to have the ability
> > to
> > edit the content?
> >
> > I see some naming that looks like url id became the Page Title:
> >
> >  For example: NuttX Initialization Sequence is listed under Initsequence
> >
> > https://cwiki.apache.org/confluence/display/NUTTXTEST/Initsequence
> >
> > Also is there a way to maintain the original authors?
> >
> > David
> >
> > -Original Message-
> > From: Brennan Ashton [mailto:bash...@brennanashton.com]
> > Sent: Sunday, December 15, 2019 11:16 PM
> > To: dev@nuttx.apache.org
> > Subject: Re: [nuttx] Wiki Backup
> >
> > Ok,
> > That was a bigger hassle than I expected.  The converter tool was
> > getting
> > tripped up with odd escaping and generating bad XML files for
> > confluence,
> > but I think it is good now.
> > I also went through and manually cleaned the naming, obvious issues, and
> > inserted a bunch of confluence macros on the pages.
> >
> > https://cwiki.apache.org/confluence/display/NUTTXTEST/Nuttx
> >
> > I think it is good to go live, but there are a few things to address:
> > 1) There are some links that were not wiki links, but url links to the
> > wiki
> > that did not get converted.  I have the sources to find all of these, so
> I
> > will tackle that soon.
> > 2a) The documentation pages are embedding the HTML documentation that is
> > on
> > nuttx.org/Documentation but once the code is moved to github/apache I
> will
> > update to pull the latest.
> > 2b) The documentation is using favicons internally as images, this is
> > not
> > valid and causes issues broken image links.  This should be fixed in the
> > code no changes are needed on the wiki.
> > 3) The presentations are linked to pdfs at nuttx.org Those PDFs should
> > just
> > become attachments to wiki pages.
> >
> > Justin if you move this to NUTTX from NUTTXTEST please add me to the
> > permissions on that space as well.
> >
> > Thanks,
> > Brennan
> >
> > On Sun, Dec 15, 2019 at 4:27 PM Gregory Nutt 
> wrote:
> >
> > >
> > > > First stab at the import went surprisingly well.  All but a few
> > > > pages
> > > > converted, unfortunately the hierarchy did not convert correctly so
> > > > I
> > > will
> > > > have to mess with it more (these tools are mostly abandoned for 8+
> > years
> > > so
> > > > at least they run).
> > > That is good news.
> > > > Greg I dont think I will need the other non wiki files since they
> were
> > > not
> > > > wiki attachments they are just external links, we will just have to
> > > > manually re-import them which should be easy enough.
> > >
> > > I am about ready to go upstairs where the internet is good and I will
> > > still transfer them.  They might come in handy for you.
> > >
> > > Greg
> > >
> > >
> > >
> > >
> >
>

[REQUIREMENTS- NuttX Workflow]

[david . sidrane]

 [REQUIREMENTS- NuttX Workflow]

I am creating this thread to gather ONLY REQUIREMENTS. See [DISCUSS - NuttX
Workflow]

After the requirements are gathered in one place we can discuss the merits
and vote on them.

RE: [nuttx] Wiki Backup

[David Sidrane]

Brennan,

Thank you for your efforts!

Justin: Is there an issue with adding all the PPMC to have the ability to
edit the content?

I see some naming that looks like url id became the Page Title:

 For example: NuttX Initialization Sequence is listed under Initsequence

https://cwiki.apache.org/confluence/display/NUTTXTEST/Initsequence

Also is there a way to maintain the original authors?

David

-Original Message-
From: Brennan Ashton [mailto:bash...@brennanashton.com]
Sent: Sunday, December 15, 2019 11:16 PM
To: dev@nuttx.apache.org
Subject: Re: [nuttx] Wiki Backup

Ok,
That was a bigger hassle than I expected.  The converter tool was getting
tripped up with odd escaping and generating bad XML files for confluence,
but I think it is good now.
I also went through and manually cleaned the naming, obvious issues, and
inserted a bunch of confluence macros on the pages.

https://cwiki.apache.org/confluence/display/NUTTXTEST/Nuttx

I think it is good to go live, but there are a few things to address:
1) There are some links that were not wiki links, but url links to the wiki
that did not get converted.  I have the sources to find all of these, so I
will tackle that soon.
2a) The documentation pages are embedding the HTML documentation that is on
nuttx.org/Documentation but once the code is moved to github/apache I will
update to pull the latest.
2b) The documentation is using favicons internally as images, this is not
valid and causes issues broken image links.  This should be fixed in the
code no changes are needed on the wiki.
3) The presentations are linked to pdfs at nuttx.org Those PDFs should just
become attachments to wiki pages.

Justin if you move this to NUTTX from NUTTXTEST please add me to the
permissions on that space as well.

Thanks,
Brennan

On Sun, Dec 15, 2019 at 4:27 PM Gregory Nutt  wrote:

>
> > First stab at the import went surprisingly well.  All but a few pages
> > converted, unfortunately the hierarchy did not convert correctly so I
> will
> > have to mess with it more (these tools are mostly abandoned for 8+ years
> so
> > at least they run).
> That is good news.
> > Greg I dont think I will need the other non wiki files since they were
> not
> > wiki attachments they are just external links, we will just have to
> > manually re-import them which should be easy enough.
>
> I am about ready to go upstairs where the internet is good and I will
> still transfer them.  They might come in handy for you.
>
> Greg
>
>
>
>

RE: [nuttx] Wiki Backup

[David Sidrane]

Thank you Justin!

I see.

So for benefit of others: Do not follow the link in the email and try to
log in.

Log into the dashboard first then follow the link there.

David

-Original Message-
From: Justin Mclean [mailto:jus...@classsoftware.com]
Sent: Monday, December 16, 2019 3:49 AM
To: dev@nuttx.apache.org
Subject: Re: [nuttx] Wiki Backup

Hi,

> Justin: Is there an issue with adding all the PPMC to have the ability
to
> edit the content?

All PPMC and committers already have edit rights.

Thanks,
Justin

Re: Contributions (PR or patches)

[David Sidrane]

I would like to reboot this. I would question some of these statements that are 
conditioned by history: Greg repeatedly stated that he hated PR and prefers 
patches. So to work with NuttX people sent patches. This is a fresh start, and 
the value of it is to be able to ASK the group what their preferred workflow 
would be and WHY. Then discuss the merits, educate each other on the value of 
approaches and then make an informed decisions. 

Davdi

On 2019/12/16 01:45:54, Gregory Nutt  wrote: 
> 
> > I am just wondering if we are excluding any users by forcing everyone 
> > to use PRs.  I personally don't have problems with mixed PRs and 
> > patches, provided that the patches apply clean.  I think we should 
> > take the side of the lowest common denominator user and NOT the point 
> > of view that makes our job the slickest.
> >
> Remember that the majority of NuttX users do not use git at all. They 
> use the release tarballs which have all GIT information stripped out.  
> No GIT and not GIT knowledge is required to use NuttX.  I don't know if 
> it is customary to strip GIT out of Apache tarballs, but still we need 
> to accept users that have no GIT skills.
> 
> It is one of the core principles of NuttX that "all users matter" and 
> that we do nothing to restrict the use of the OS, especially not to make 
> out internal life simpler at the expense of a world of users.  We should 
> do the opposite; we should keep the complexit o y inside the project and 
> do all we can to make NuttX accessible to all users.
> 
> Greg
> 
> 

Re: Contributions (PR or patches)

[David Sidrane]

> So, how will we keep track of approvals? I assume that GitHub has a built
in mechanism for this purpose?

Nathan,

Yes it if built for this and from my perspective working on a 93 person team, 
with 67 repositories. It is highly efficient, collaborative, and effective.

For example:
Ignoring the excellent process integration to create a proper work flow that 
keeps master clean and building with full CI integration.

Have a look Suggested changes: 
 Suppose you’re collaborating on a repository with an active pull request. A 
reviewer can look at that pull request, and if they see room for improvement, 
suggest a change to the code by leaving a comment. The author can then accept 
the suggestion with a single click.

DRAFT PR. You want input on a design. Create a draft PR, get all the input and 
value add the community has to offer. That will not be merged before it is 
ready. 

Here is the value I see in this from past experiences: I have had multiple ways 
to solve a problem and wanted to get the collective expert's feed back. I Put 
up a PR for discussion marking it a Work In Progress [WIP] and the next thing I 
know, my WIP was merged.

>From my perspective patches, unless applied to a branch do not offer a 
>collaborative resolution method- nor do they provide a way to educate the 
>community, without an undo effort to decode the delta for the contributed 
>patch to what was applied (speaking of the past process). 

Let's get some requirements defined, our goals laid out and then discuss the 
pros and cons of the options for workflow and the tools that exits the make the 
whole of the PPMC productive. I am reflecting on statements like, "Volunteers 
with full time jobs" and "Simple for users." We owe it to ourselves and the 
community to make this efficient and effective. 

David

On 2019/12/16 03:35:01, Xiang Xiao  wrote: 
> Yes, GitHub has the standard workflow, we just need insert our special
> requirement(style, build and test) into it:
> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/github-flow
> Here is one example mynewt:
> https://github.com/apache/mynewt-core/pull/2126
> 
> Thanks
> Xiang
> On Mon, Dec 16, 2019 at 10:56 AM Nathan Hartman
>  wrote:
> >
> > On Sun, Dec 15, 2019 at 9:12 PM Gregory Nutt  wrote:
> >
> > > Sorry to keep running on...
> > >
> > > Another thing is that we do not want dictate to uses of release what
> > > configuration management tools they must use.  In our open source
> > > culture, GIT is pervasive, but remember that many corporations prefer
> > > commercial SCM systems.
> >
> >
> > Case in point: My $company uses a really awesome SCM: Apache Subversion :-)
> >
> > So the process is something along these lines:
> >
> > (Please fill in any gaps...)
> >
> > Will we receive a patch, which I'm assuming will come to dev@ in the form
> > of email attachments, then a NuttX committer looks at it, sees if it looks
> > reasonable, then converts that into a GitHub PR.
> >
> > Which begs the question: how do we keep track of emailed patches being
> > processed? Perhaps as simple as a committer replying to the email to say
> > that it's being processed?
> >
> > Once at GitHub then automated tests run (including nxstyle), then ... ???
> >
> > In certain parts of the system, I think we should have reasonably low
> > barriers to getting contributions in. Drivers for adding, say, SPI support
> > to some chip shouldn't require too much scrutiny provided they meet the
> > coding standard...
> >
> > But:
> >
> > In some critical parts, including the build system and OS internals like
> > the scheduler, we need a process whereby several pairs of eyes will look at
> > the PR and agree that it should be merged. For example, say, we need N +1s
> > and zero -1s for any changes that affect those parts... (the value of N
> > will need discussion but that is a subject for another day).
> >
> > So, how will we keep track of approvals? I assume that GitHub has a built
> > in mechanism for this purpose?
> >
> > Nathan
> 

RE: [nuttx] Wiki Backup

[David Sidrane]

Brennan,

I bet it was grueling. Thank you again Brennan!

David
-Original Message-
From: Brennan Ashton [mailto:bash...@brennanashton.com]
Sent: Monday, December 16, 2019 7:50 AM
To: dev@nuttx.apache.org
Subject: Re: [nuttx] Wiki Backup

Greg and David,
The page names just need to finish getting updated, I did about 80% of
them. I can finish that today, I just needed to go to sleep last night.
Manually clicking through all the pages was grating on me.

--Brennan

On Mon, Dec 16, 2019, 3:21 AM David Sidrane  wrote:

> Brennan,
>
> Thank you for your efforts!
>
> Justin: Is there an issue with adding all the PPMC to have the ability to
> edit the content?
>
> I see some naming that looks like url id became the Page Title:
>
>  For example: NuttX Initialization Sequence is listed under Initsequence
>
> https://cwiki.apache.org/confluence/display/NUTTXTEST/Initsequence
>
> Also is there a way to maintain the original authors?
>
> David
>
> -Original Message-
> From: Brennan Ashton [mailto:bash...@brennanashton.com]
> Sent: Sunday, December 15, 2019 11:16 PM
> To: dev@nuttx.apache.org
> Subject: Re: [nuttx] Wiki Backup
>
> Ok,
> That was a bigger hassle than I expected.  The converter tool was getting
> tripped up with odd escaping and generating bad XML files for confluence,
> but I think it is good now.
> I also went through and manually cleaned the naming, obvious issues, and
> inserted a bunch of confluence macros on the pages.
>
> https://cwiki.apache.org/confluence/display/NUTTXTEST/Nuttx
>
> I think it is good to go live, but there are a few things to address:
> 1) There are some links that were not wiki links, but url links to the
> wiki
> that did not get converted.  I have the sources to find all of these, so I
> will tackle that soon.
> 2a) The documentation pages are embedding the HTML documentation that is
> on
> nuttx.org/Documentation but once the code is moved to github/apache I will
> update to pull the latest.
> 2b) The documentation is using favicons internally as images, this is not
> valid and causes issues broken image links.  This should be fixed in the
> code no changes are needed on the wiki.
> 3) The presentations are linked to pdfs at nuttx.org Those PDFs should
> just
> become attachments to wiki pages.
>
> Justin if you move this to NUTTX from NUTTXTEST please add me to the
> permissions on that space as well.
>
> Thanks,
> Brennan
>
> On Sun, Dec 15, 2019 at 4:27 PM Gregory Nutt  wrote:
>
> >
> > > First stab at the import went surprisingly well.  All but a few pages
> > > converted, unfortunately the hierarchy did not convert correctly so I
> > will
> > > have to mess with it more (these tools are mostly abandoned for 8+
> years
> > so
> > > at least they run).
> > That is good news.
> > > Greg I dont think I will need the other non wiki files since they were
> > not
> > > wiki attachments they are just external links, we will just have to
> > > manually re-import them which should be easy enough.
> >
> > I am about ready to go upstairs where the internet is good and I will
> > still transfer them.  They might come in handy for you.
> >
> > Greg
> >
> >
> >
> >
>

Re: [DISCUSS - NuttX Workflow]

[David Sidrane]

> 5 issue one pull request from your fork nuttx/apps to apache nuttx/apps 
> master branch

Are you suggesting we have one repo NuttX with 2 folders apps and nuttx?

That will simplify everything! - but I suspect we will receive STRONG arguments 
against it.
 
So you  say "one pull request" 

Where? You have 2 repos. PR are against a single repo.

This it what the Knot does. - It is the where

On 2019/12/18 10:09:26, Alan Carvalho de Assis  wrote: 
> Hi Liu,
> 
> On Wednesday, December 18, 2019, Haitao Liu  wrote:
> > How about just keep two separate git repositories (apps and nuttx
> > projects) instead
> > of add a parent knot repo with apps and nuttx as sub-modules?
> > As to jenkins CI, I haven’t found proper github plugin to get PRs from
> > multiple repos(especially PRs dependency in apps & nuttx ) in one Jenkins
> > job.  Before that, I wonder whether we could keep it simple and
> > directly, create
> > one jenkins job for apps and another  jenkins job for nuttx to process PR
> > trigger accordingly.  Just make sure the jenkins pipeline or build script
> > to sync both apps and nuttx repos, then pick the apps or nuttx PR to do
> > full build.
> >
> > Since nuttx and apps projects keeps same as before, developers adapt to
> > github workflow as usual:
> > 1 fork the official apache nuttx & apps projects in github
> > 2 git clone your fork projects locally
> > 3 edit locally and then git commit to local branch
> > 4 git push to your github fork nuttx/apps branch
> > 5 issue one pull request from your fork nuttx/apps to apache nuttx/apps
> > master branch
> > 6 jenkins CI auto-trigger: style check, build or test, if failed, go to
> > step 3, continue 3 ~ 7
> > 7 PMC start to review PR, review ok, merge to master; or review failed, go
> > to step 3, continue 3~7
> >
> > Detailed info about GitHub workflow:
> >
> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests
> >
> 
> I agree! Using two repositores is better than creating submodules.
> 
> We Just need to guarantee that users will clone both directories. The build
> system can do it when the user try to build without the ../apps.
> 
> BR,
> 
> Alan
> 

Re: [DISCUSS - NuttX Workflow]

[David Sidrane]

Hi, 

Sharing my thoughts here for discussion.

=== Source code checking 

Prior to submission, the submission shall be checked by a source code 
beatify-er. 

REQ1: The submission shall not be possible without a local check passing.
REQ2: A tool shall be used to check the NuttX coding standard.
REQ3: A tool shall be used to check for ASF licence compliance.
REQ4: A tool shall be used to check for blank lines at the end of files.

DREQ1) An gold standard source code file need to be created to validate tool.

Option a) Enhance nxstyle to
   i. To be complete
   ii. Support class of errors: errors, warnings, info
  iii. Support format options that fixes the files
  iv. At a minimum give compiler output error message that allow rapid fixing 
of the source in a compiler output aware editor. vi, UE, VC, Eclipse.

Options b) use a mature tool such as Astyle, Uncrutstify, clang format - train 
it with https://github.com/mikr/whatstyle.

Option c) Cascade a combination of a & b to get the last 2% that option a can 
not.

Option d)  Make minimal coding standard changes that can be 100% supported by 
option a.*

*) Greg suggested this in the bar at NuttX2019 - caveat it was in the BAR!


On 2019/12/17 09:36:28, david.sidr...@gmail.com wrote: 
>  [DISCUSS - NuttX Workflow]
> 
> I am creating this thread to discuss what we as a community would like to
> have as NuttX Workflow. I have also created [REQUIREMENTS- NuttX Workflow]
> I am asking us to not add discussion to [REQUIREMENTS- NuttX Workflow].
> Please do that here.
> 
> As this discussion evolves we shall create requirements and add them
> to the [REQUIREMENTS-
> NuttX Workflow] thread.
> 
> Please use [DISCUSS - NuttX Workflow] to propose and discuss the ideas
> and experiences
> you have to offer.
> 
> Be detailed; give examples, list pros and cons, why you like it and why you
> don't.
> 
> Then after the requirements are gathered in one place and discussed here
> then can vote on them.
> 
> Thank you.
> 
> David
> 

RE: patch for ntpclient: merge xmit and recv buffer into one to save the stack

[David Sidrane]

+1

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Tuesday, December 17, 2019 8:07 PM
To: dev@nuttx.apache.org
Subject: Re: patch for ntpclient: merge xmit and recv buffer into one to
save the stack

> Should we enable the attachment before the new workflow settle? so the
> traditional workflow can transfer from google group to here
> immediately.

There is no reason to send patches to any of the Apache resources now.
They cannot be used there until the repositories are in place and we
have at least a functional description of the workflow.  All patches
will be applied to the Bitbucket repositories until that two things are
in place.  I suggest that you continue to send patch to the Google group
until then.

Greg

Re: [DISCUSS - NuttX Workflow]

[David Sidrane]

That is precisely what submodules do:submodules aggregate on a single SHAL N 
repositories.

The problem is: How to have atomic checkout of the correct configuration with 
out a temporal shift?

Please describe how you would do this. Give detailed steps.

On 2019/12/18 10:09:26, Alan Carvalho de Assis  wrote: 
> Hi Liu,
> 
> On Wednesday, December 18, 2019, Haitao Liu  wrote:
> > How about just keep two separate git repositories (apps and nuttx
> > projects) instead
> > of add a parent knot repo with apps and nuttx as sub-modules?
> > As to jenkins CI, I haven’t found proper github plugin to get PRs from
> > multiple repos(especially PRs dependency in apps & nuttx ) in one Jenkins
> > job.  Before that, I wonder whether we could keep it simple and
> > directly, create
> > one jenkins job for apps and another  jenkins job for nuttx to process PR
> > trigger accordingly.  Just make sure the jenkins pipeline or build script
> > to sync both apps and nuttx repos, then pick the apps or nuttx PR to do
> > full build.
> >
> > Since nuttx and apps projects keeps same as before, developers adapt to
> > github workflow as usual:
> > 1 fork the official apache nuttx & apps projects in github
> > 2 git clone your fork projects locally
> > 3 edit locally and then git commit to local branch
> > 4 git push to your github fork nuttx/apps branch
> > 5 issue one pull request from your fork nuttx/apps to apache nuttx/apps
> > master branch
> > 6 jenkins CI auto-trigger: style check, build or test, if failed, go to
> > step 3, continue 3 ~ 7
> > 7 PMC start to review PR, review ok, merge to master; or review failed, go
> > to step 3, continue 3~7
> >
> > Detailed info about GitHub workflow:
> >
> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests
> >
> 
> I agree! Using two repositores is better than creating submodules.
> 
> We Just need to guarantee that users will clone both directories. The build
> system can do it when the user try to build without the ../apps.
> 
> BR,
> 
> Alan
> 

RE: [DISCUSS - NuttX Workflow]

[David Sidrane]

Hi Sebastien,

I agree submodules are a PAIN! But I do not agree this is hard it is just
more steps.

This why:  Because on a busy project it will break the build and/or cause
code to not get run.
It will waist time debugging ghosts and creating problem posts to list of
issues that are not reproducible.

No matter what anyone thinks architecturally  - There are dependencies from
apps to nuttx and nuttx to apps.

Two examples:

1 ) Change: CONFIG_EXAMPLE_IRBLASTER -> CONFIG_EXAMPLE_IR_BLASTER

In all the defconfig files on nuttx then on apps


push nuttx
->>>>>>>>You pull
push apps

Oh my code is broken it does not even run the ir blaster

OR

2) Add a new OS syscall

push apps
->>>>>>>>You pull
push nuttx

Oh the build is broken


If you want to roll the dice you can - do your old work flow NOTHING is
stopping you from it just check or the two repos not the knot repo do it all
by hand.

David


-Original Message-
From: Sebastien Lorquet [mailto:sebast...@lorquet.fr]
Sent: Wednesday, December 18, 2019 2:58 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS - NuttX Workflow]

why completely change what has worked for years?

2 repos as always. Submodules are an absolute pain to manage when you have
branches.

people have always been cloning two repos.

devs were sending patches for one of them.

Now they send pull request instead. Better tracking, ability to fix while
being
reviewed...

pull requests require branches, that will be annoying with submodules. This
will
still require separate pull requests for apps and nuttx.

I have NEVER seen any contribution that really required an exactly atomic
update
to both repos.

People often send patches for nuttx, and sometimes for apps.

Why change that?

Sebastien

Le 18/12/2019 à 11:46, David Sidrane a écrit :
>> 5 issue one pull request from your fork nuttx/apps to apache nuttx/apps
>> master branch
> Are you suggesting we have one repo NuttX with 2 folders apps and nuttx?
>
> That will simplify everything! - but I suspect we will receive STRONG
> arguments against it.
>
> So you  say "one pull request"
>
> Where? You have 2 repos. PR are against a single repo.
>
> This it what the Knot does. - It is the where
>
> On 2019/12/18 10:09:26, Alan Carvalho de Assis  wrote:
>> Hi Liu,
>>
>> On Wednesday, December 18, 2019, Haitao Liu  wrote:
>>> How about just keep two separate git repositories (apps and nuttx
>>> projects) instead
>>> of add a parent knot repo with apps and nuttx as sub-modules?
>>> As to jenkins CI, I haven’t found proper github plugin to get PRs from
>>> multiple repos(especially PRs dependency in apps & nuttx ) in one
>>> Jenkins
>>> job.  Before that, I wonder whether we could keep it simple and
>>> directly, create
>>> one jenkins job for apps and another  jenkins job for nuttx to process
>>> PR
>>> trigger accordingly.  Just make sure the jenkins pipeline or build
>>> script
>>> to sync both apps and nuttx repos, then pick the apps or nuttx PR to do
>>> full build.
>>>
>>> Since nuttx and apps projects keeps same as before, developers adapt to
>>> github workflow as usual:
>>> 1 fork the official apache nuttx & apps projects in github
>>> 2 git clone your fork projects locally
>>> 3 edit locally and then git commit to local branch
>>> 4 git push to your github fork nuttx/apps branch
>>> 5 issue one pull request from your fork nuttx/apps to apache nuttx/apps
>>> master branch
>>> 6 jenkins CI auto-trigger: style check, build or test, if failed, go to
>>> step 3, continue 3 ~ 7
>>> 7 PMC start to review PR, review ok, merge to master; or review failed,
>>> go
>>> to step 3, continue 3~7
>>>
>>> Detailed info about GitHub workflow:
>>>
>> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests
>> I agree! Using two repositores is better than creating submodules.
>>
>> We Just need to guarantee that users will clone both directories. The
>> build
>> system can do it when the user try to build without the ../apps.
>>
>> BR,
>>
>> Alan
>>

Re: [DISCUSS - NuttX Workflow]

[David Sidrane]

>I haven’t found proper github plugin to get PRs from multiple repos(especially 
>PRs dependency 

1) How would you create a way to do this. 

Hows about we add a file to the repo with the 2 shals in it and hand edit it 
before every push?

["NuttX/nuttx"]
path = NuttX/nuttx
url = https://github.com/NuttX/NuttX.git
SHAL = 2757647897a6f1c3451180b4c242aec25185523e
["NuttX/apps"]
path = NuttX/apps
url = https://github.com/NuttX/apps.git
SHAL = 01818b505f898f33176bf90f9563e84942ea56cf

2) Why would this exist if git supports it already?

this is what submodules are:

https://github.com/PX4/Firmware/blob/master/.gitmodules
..
[submodule "platforms/nuttx/NuttX/nuttx"]
path = platforms/nuttx/NuttX/nuttx
url = https://github.com/PX4/NuttX.git
branch = px4_firmware_nuttx-8.2
[submodule "platforms/nuttx/NuttX/apps"]
path = platforms/nuttx/NuttX/apps
url = https://github.com/PX4/NuttX-apps.git
branch = px4_firmware_nuttx-8.2


On 2019/12/18 09:51:45, Haitao Liu  wrote: 
> How about just keep two separate git repositories (apps and nuttx
> projects) instead
> of add a parent knot repo with apps and nuttx as sub-modules?
> As to jenkins CI, I haven’t found proper github plugin to get PRs from
> multiple repos(especially PRs dependency in apps & nuttx ) in one Jenkins
> job.  Before that, I wonder whether we could keep it simple and
> directly, create
> one jenkins job for apps and another  jenkins job for nuttx to process PR
> trigger accordingly.  Just make sure the jenkins pipeline or build script
> to sync both apps and nuttx repos, then pick the apps or nuttx PR to do
> full build.
> 
> Since nuttx and apps projects keeps same as before, developers adapt to
> github workflow as usual:
> 1 fork the official apache nuttx & apps projects in github
> 2 git clone your fork projects locally
> 3 edit locally and then git commit to local branch
> 4 git push to your github fork nuttx/apps branch
> 5 issue one pull request from your fork nuttx/apps to apache nuttx/apps
> master branch
> 6 jenkins CI auto-trigger: style check, build or test, if failed, go to
> step 3, continue 3 ~ 7
> 7 PMC start to review PR, review ok, merge to master; or review failed, go
> to step 3, continue 3~7
> 
> Detailed info about GitHub workflow:
> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests
> 
>  于2019年12月17日周二 下午5:36写道：
> 
> >  [DISCUSS - NuttX Workflow]
> >
> > I am creating this thread to discuss what we as a community would like to
> > have as NuttX Workflow. I have also created [REQUIREMENTS- NuttX Workflow]
> > I am asking us to not add discussion to [REQUIREMENTS- NuttX Workflow].
> > Please do that here.
> >
> > As this discussion evolves we shall create requirements and add them
> > to the [REQUIREMENTS-
> > NuttX Workflow] thread.
> >
> > Please use [DISCUSS - NuttX Workflow] to propose and discuss the ideas
> > and experiences
> > you have to offer.
> >
> > Be detailed; give examples, list pros and cons, why you like it and why you
> > don't.
> >
> > Then after the requirements are gathered in one place and discussed here
> > then can vote on them.
> >
> > Thank you.
> >
> > David
> >
> 

Re: [Degrees of freedom under ASF ]

[David Sidrane]

Thank you Justin for the quick answers! 

1 more below

On 2019/12/19 14:00:36, Justin Mclean  wrote: 
> Hi,
> 
> > I would like to get some clarification on the projects degrees of freedom
> > under ASF from our mentors.
> 
> As long as you follow the Apache Way you are free to do what you want. We 
> have a lot of history and over time have built up guidelines which describe 
> what has worked well. Sometimes it's not obvious why these guidelines may 
> exists, so ask if you don’t know or understand or think they seem strange. 
> Sometimes these guideline might not work for your project, that’s OK, if you 
> want to do things in a different way discuss it with the incubator PMC. There 
> is not one path for all projects.
> 
> > Am I correct in understanding that ASF requires project dev communications
> > to be in the open and publicly available” ?
> 
> Yes.
> 
> > Does this need to be on only these mailing lists we have been provided by
> > ASF? 
> 
> It’s preferable yes. But if they can be archived and searchable that’s fine. 
> Often a solution is automatically sending that conversion to a mailing list 
> or bringing back a summary to the list.

Do I understand you correctly? We can use the original google group and add a 
user there with the dev@nuttx.apache.org?

> 
> > I ask this for the reason that the lists are very hard to follow.
> 
> Use subject line to guide you, Id suggest using an email client that supports 
> threads and rules to group messages. You don’t have to read everything. Given 
> it is early days, there’s a lot of noise, I think this will get better over 
> time.
> 
> > Who is the moderator on a list?
> 
> There’s a couple of moderators, if you want to be one just ask, but that’s 
> more to accept/reject emails from people who are not subscribed. All emails 
> from a subscribed address are automatically accepted.
> 
> > - If someone is being abusive is that left on the list forever?
> 
> In general yes. It hard to remove emails and they are archived in many public 
> places.
> 
> > How does one correct a mistake in their post?
> 
> Generally just reply and correct the mistake.
> 
> > Is it an ASF edict to not use the existing NuttX slack?
> 
> No but we would prefer conversation on the mailing list for reasons mentioned 
> above.
> 
> > Other than the release procedures and distribution tools/locations is the
> > project free to use any tool we want for development, testing and CI?
> 
> In general yes. Some tools are easier to use as Infra already supports them.
> 
> > Given the history in the name of  ASF: Are we required to support changes
> > by patches?
> > -  What tool does apache support for avoiding duplicate work on
> > patches? Is there a semaphore?
> >- How does a group review a patch collaboratively?
> 
> There’s no ASF requirements here, it's up to the project to work that out.
> 
> Hope that helps and answer your questions. If you have any or just ask.
> 
> Thanks,
> Justin

[Degrees of freedom under ASF ]

[David Sidrane]

I would like to get some clarification on the projects degrees of freedom
under ASF from our mentors.

Since we are all (except a few) new to the “Apache way” I think we need
some enlightenment.

I feel it is important that we, as a group, understand what are
guidelines, rules and absolutes.

I do not want to be taking statements out of context and acting on them
without asking questions as this could severely curtail the growth of this
project.


=== Questions ===

Am I correct in understanding that ASF requires project dev communications
to be in the open and publicly available” ?

Does this need to be on only these mailing lists we have been provided by
ASF? Or can we be using Google Groups and mirror the reference the list?

I ask this for the reason that the lists are very hard to follow. Granted
I may be using them wrong, but having 150 emails a day that lack any
context is more noise than signal and I find it a HUGE a waste of time. If
this is the only option I am open to be instructed on how to use them
better.

Who is the moderator on a list?
- If someone is being abusive is that left on the list forever?
How does one correct a mistake in their post?

Is it an ASF edict to not use the existing NuttX slack?

Other than the release procedures and distribution tools/locations is the
project free to use any tool we want for development, testing and CI?

Given the history in the name of  ASF: Are we required to support changes
by patches?
-  What tool does apache support for avoiding duplicate work on
patches? Is there a semaphore?
- How does a group review a patch collaboratively?


David

RE: Contributions (PR or patches)

[David Sidrane]

+1

-Original Message-
From: Brennan Ashton [mailto:bash...@brennanashton.com]
Sent: Thursday, December 19, 2019 1:20 AM
To: dev@nuttx.apache.org
Subject: Re: Contributions (PR or patches)

It would be really nice if we could get all patch series to go into PRs,
even if we don't have the QA and everything setup yet.  I would be happy to
automate that via something like patchwork if that is of any help.

--Brennan

On Thu, Dec 19, 2019, 12:56 AM Flavio Junqueira  wrote:

> Patches through the email list are acceptable [1]. It is harder to track
> issues and implement an effective workflow (e.g., running QA builds, code
> reviews) for contributions via the list, but from a legal standpoint, it
> is
> acceptable.
>
> -Flavio
>
> [1] https://www.apache.org/foundation/how-it-works/legal.html <
> https://www.apache.org/foundation/how-it-works/legal.html>
>
> > On 19 Dec 2019, at 09:15, Alin Jerpelea  wrote:
> >
> > I agree that we should use both.
> >
> > Personally I like github PR since we can do code review and automated
> > testing on PR
> > With some manual work we can also handle patches as long as they apply
> > clean and someone will spend the time to test them manually.
> >
> > Regards
> > Alin
> >
> >
> > On Mon, Dec 16, 2019 at 12:56 PM David Sidrane 
> wrote:
> >
> >>> So, how will we keep track of approvals? I assume that GitHub has a
> built
> >> in mechanism for this purpose?
> >>
> >> Nathan,
> >>
> >> Yes it if built for this and from my perspective working on a 93 person
> >> team, with 67 repositories. It is highly efficient, collaborative, and
> >> effective.
> >>
> >> For example:
> >> Ignoring the excellent process integration to create a proper work flow
> >> that keeps master clean and building with full CI integration.
> >>
> >> Have a look Suggested changes:
> >> Suppose you’re collaborating on a repository with an active pull
> request.
> >> A reviewer can look at that pull request, and if they see room for
> >> improvement, suggest a change to the code by leaving a comment. The
> author
> >> can then accept the suggestion with a single click.
> >>
> >> DRAFT PR. You want input on a design. Create a draft PR, get all the
> input
> >> and value add the community has to offer. That will not be merged
> before it
> >> is ready.
> >>
> >> Here is the value I see in this from past experiences: I have had
> multiple
> >> ways to solve a problem and wanted to get the collective expert's feed
> >> back. I Put up a PR for discussion marking it a Work In Progress [WIP]
> and
> >> the next thing I know, my WIP was merged.
> >>
> >> From my perspective patches, unless applied to a branch do not offer a
> >> collaborative resolution method- nor do they provide a way to educate
> the
> >> community, without an undo effort to decode the delta for the
> contributed
> >> patch to what was applied (speaking of the past process).
> >>
> >> Let's get some requirements defined, our goals laid out and then
> >> discuss
> >> the pros and cons of the options for workflow and the tools that exits
> the
> >> make the whole of the PPMC productive. I am reflecting on statements
> like,
> >> "Volunteers with full time jobs" and "Simple for users." We owe it to
> >> ourselves and the community to make this efficient and effective.
> >>
> >> David
> >>
> >> On 2019/12/16 03:35:01, Xiang Xiao  wrote:
> >>> Yes, GitHub has the standard workflow, we just need insert our special
> >>> requirement(style, build and test) into it:
> >>>
> >>
> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/github-flow
> >>> Here is one example mynewt:
> >>> https://github.com/apache/mynewt-core/pull/2126
> >>>
> >>> Thanks
> >>> Xiang
> >>> On Mon, Dec 16, 2019 at 10:56 AM Nathan Hartman
> >>>  wrote:
> >>>>
> >>>> On Sun, Dec 15, 2019 at 9:12 PM Gregory Nutt 
> >> wrote:
> >>>>
> >>>>> Sorry to keep running on...
> >>>>>
> >>>>> Another thing is that we do not want dictate to uses of release what
> >>>>> configuration management tools they must use.  In our open source
> >>>>> culture, GIT is pervasive, but remember that many corporations
> >>>>>

RE: [DISCUSS - NuttX Workflow]

[David Sidrane]

This reads like a past slack discussion that ignored HW.
Is that really what an embedded system OS should do?

> Changes to code in MCU architectural support, board support, or features
> in the periphery of the OS should be at the discretion of the
> committer. Committers should use their best judgment and are
> encouraged to discuss anything they're not sure about. But these
> changes don't require as much oversight. These changes are much more
> limited in their exposure. They are usually developed by someone to
> scratch their own itch. Also these are allowed to be feature-
> incomplete: e.g., it is okay to have partial board support.

I do not agree. MCU and board changes need better scrutiny for many reasons,
here are some:

1) Proper patterns applied. This gets misses a lot - consider the "ifdef
rash" and missed invilotes
2) Proper scoping - this just happened in imxrt
3) They still can break the build.
3) They still can ruin the OS's reputation.
4) This is where HW background is needed.

You may want to consider separate levels of scrutiny for MCU's than boards.

One is a many to 1 relation.
One is a 1 to 1.

David

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Thursday, December 19, 2019 10:33 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS - NuttX Workflow]


>> I think only 5 emails in the whole list really address these functional
>> requirements.
> Let me add a 6th... (Without mentioning any "stupid" SCMs.)
>
> One thing missing from our earlier discussions is to decide how many
> approvals a change requires. I think this varies by area of the code
> being changed.
>
> As a starting point for further discussion, I suggest something along
> these lines:
>
> Changes that affect the build system should require three +1 binding
> votes and no vetoes from PMC members PLUS at least one report that
> NuttX builds successfully on each supported platform: Windows, Mac,
> Unix, and no reports of breakage caused by the change. Builds on
> Windows using a Unix compatibility layer would be considered Unix for
> this purpose. Any member of the community should be able to report
> whether it builds successfully and on which platform. Between the
> submitter of the patch, PMC members, and testers, this means that at
> least 7 pairs of eyes looks at any change to the build system. This
> high number is necessary because breakage there affects everyone and
> is very disruptive!
>
> Changes to code that affect the core of the OS should require three +1
> binding votes and no vetoes from PMC members and should be accompanied
> by some rationale or justification for the change. If applicable,
> supporting data should be provided, e.g., if it's supposed to improve
> performance, is this backed up by measurements?
>
> Changes to code in MCU architectural support, board support, or features
> in the periphery of the OS should be at the discretion of the
> committer. Committers should use their best judgment and are
> encouraged to discuss anything they're not sure about. But these
> changes don't require as much oversight. These changes are much more
> limited in their exposure. They are usually developed by someone to
> scratch their own itch. Also these are allowed to be feature-
> incomplete: e.g., it is okay to have partial board support.
>
> In the apps repository: Changes to code in core apps (such as NSH)
> should require two +1 binding votes and no vetoes.
>
> Changes to other non-core areas of apps are at the discretion of the
> committer.
>
> Notwithstanding all of the above, there is the concept of an "obvious
> fix." Any committer may fix things like obvious typos, misspellings,
> grammar mistakes in comments, code formatting violations, that do not
> change the behavior of the code, without the need for voting and
> approvals, etc. Committers are expected to exercise their best
> judgment here.
>
> It is expected that when someone votes +1 on a change, it means that:
>
> * They have studied the change
>
> * Verified that the change meets INVIOLABLES.
>
> * Verified that it does not break POSIX compatibility or OS
> architectural boundaries
>
> * Done testing if feasible
>
> * Weighed any input from the community
>
> Please remember, the above are NOT rules, the above is a starting
> point for discussion as we hash out our requirements.
>
> Please participate, offer your thoughts, criticisms, etc.
>
> Thanks,
> Nathan

Those sound like good rules of thumb to me.  Certainly there are parts
of the OS that require more care and have broader impact that others.

RE: [DISCUSS - NuttX Workflow]

[David Sidrane]

Greg, please read the first post again.

RE: Workflow and Release strategy Proposal (Was RE: Project Emails)

[David Sidrane]

By who? Where is the vote?

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Thursday, December 19, 2019 5:45 AM
To: dev@nuttx.apache.org
Subject: Re: Workflow and Release strategy Proposal (Was RE: Project Emails)


> Why would you want to shut down your slack space? Some projects use a
> slack space and even the ASF has one: the-asf.slack.com
I was asked to shut down all NuttX project communications that are not
publicly visible.  I have done that.  It was a slow gradual phase out,
described in the Google group.

RE: Test Repository

[David Sidrane]

Greg,

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Friday, December 20, 2019 4:32 PM
To: dev@nuttx.apache.org
Subject: Re: Test Repository

> Looking at https://gitbox.apache.org/repos/, I see several projects,
> perhaps most projects, that have a special repository just to contain
> testing logic.  Often this is named -testing and often is has
> other names (like integration and others).
>
> So there is a precedence for a nuttx-testing repository to hold
> testing data... Things like yml files and the like.  I would much
> prefer to a have a separate repository to hold test files than to
> contaminate the incubator-nuttx and incubator-nuttx-apps repositories
> with test data.
>
> Another thing that I note by googling ".gitmodules testing
> site:github.com/apache" is that many of these testing directories also
> contain submodules to coordinate testing.  I have gotten to rather
> like the idea of three repositories:  incubator-nuttx,
> incubator-nuttx-apps, and incubator-nuttx-testing that holds all of
> the test logic with we really don't want to contaminate the user
> facing repositories with.  Best to put testing logic in one place and
> keep the end-user repositories as clean as possible to support the
> user needs.
>
I know, I am violating my own principles.  We should not really be
discussing testing repository organization UNTIL we have established,
agreed-upon workflow requirements.  We don't have any such requirements
so just think of this as idle talk.  For me it clarifies my position on
this.  I am not in favor of any mechanization that keeps the end-user
repositories and clean as possible.

Greg

>I am not in favor of any mechanization that keeps the end-user
repositories and clean as possible.

Is it?

s/not/now

RE: Test Repository

[David Sidrane]

+1

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Friday, December 20, 2019 4:29 PM
To: dev@nuttx.apache.org
Subject: Test Repository

Looking at https://gitbox.apache.org/repos/, I see several projects,
perhaps most projects, that have a special repository just to contain
testing logic.  Often this is named -testing and often is has
other names (like integration and others).

So there is a precedence for a nuttx-testing repository to hold testing
data... Things like yml files and the like.  I would much prefer to a
have a separate repository to hold test files than to contaminate the
incubator-nuttx and incubator-nuttx-apps repositories with test data.

Another thing that I note by googling ".gitmodules testing
site:github.com/apache" is that many of these testing directories also
contain submodules to coordinate testing.  I have gotten to rather like
the idea of three repositories:  incubator-nuttx, incubator-nuttx-apps,
and incubator-nuttx-testing that holds all of the test logic with we
really don't want to contaminate the user facing repositories with.
Best to put testing logic in one place and keep the end-user
repositories as clean as possible to support the user needs.

Greg

[CALL for TOP Down workflow Requirements]

[David Sidrane]

All,

Please help flesh this out.
 
Proposed Workflow Requirements (REQ) and Derived Requirements (DREQ)

REQ1) master is branches of apps and nuttx have to always build
  REQ1.1) ALL development work is done on branches.
DREQ1.1.1) master is branch protected prevention pushes to it.

REQ2) git bisect shall always be able to build master of the project at every 
commit.
 DREQ2.a) merges to master may use squash commits from a PR when atomic 
commits are needed to insure REC2.
  DREQ2.b) merges to master may use rebase commits from a PR when NON 
atomic commits will for insure REC2.

REQ3) Submissions shall be PRs against branches typically master. But PR shall 
be accepted against other branches.
  (i.e netlink_crypto)
REQ3.1) naming conventions shall reflect lineage: 
   REQ3.1.a) naming conventions of branches shall be in the form 
_ 
   master_pr-add_imxrt20, netlink_crypto-pr-bugfix_AES
   REQ3.1.b) submissions affecting multiple repos shall use the same branches 
name on all repos.
  DREQ3.1.b.1) CI shall test multiple repos by branch name
 
REQ4) committer may collaborate on branches.

REC5) While PR's are preferred, patches may be accepted.
   DREC5.1) Committers receiving patches shall apply them to a new branch (per 
REQ3) and open a PR.
REC5.1) Committers shall attribute work to the person submitting patch

REC6) All PR requires a review.
 DREC6.1) the project shall publish a list of subject experts
  REC6.1) Request for review shall be made via email to subject experts or PPMC.
  REC6.1.1)  Multiple reviewers shall be required on OS internals.
  REC6.1.2)  Multiple reviewers may be required on NON OS internals.


David

RE: Apache NuttX website

[David Sidrane]

+1

-Original Message-
From: Brennan Ashton [mailto:bash...@brennanashton.com]
Sent: Friday, December 20, 2019 8:54 PM
To: dev@nuttx.apache.org
Subject: Re: Apache NuttX website

Could we create the repo for the website.
http://www.apache.org/dev/project-site.html

The one I created is based off the Jekyll template as discussed here.
https://incubator.apache.org/guides/sites.html#publishing_your_website

RE: Testing the new repository

[David Sidrane]

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Friday, December 20, 2019 2:02 PM
To: dev@nuttx.apache.org
Subject: Re: Testing the new repository


>> We you can see the new repository is working fine.
>>
>> I submitted the i2C driver for STM32G070/NUCLEO-G070RB that was added
>> to bitbucket.
>>
>> As a rules of thumb, please don't commit directly to the "master".

+1

We should ask if info can branch protected master (settings panel in GH),
but I have no idea how or if that will work the ASF cross sync.

>>
>> I created a brash called "stage" that we could use before merging in
>> to "master", this way other will have the chance to review.

>That seems like a good sense.  Except aren't you creating a workflow
>definition from thin air.  I suppose that is natural in a vaccum -- even
>thin air is more substantial than a vacuum -- but we really need to
>define such rules in a workflow requirements document.

In an a attempt to fill the vaccum  - A skeleton [CALL for TOP Down workflow
Requirements] has been posted

Please help update and integrate what you want from the previous discussion

[PATCH] imxrt fixes FW: [apache/incubator-nuttx] imxrt fixes (#1)

[David Sidrane]

PATCH is here
https://patch-diff.githubusercontent.com/raw/apache/incubator-nuttx/pull/1.patch



PR is here https://github.com/apache/incubator-nuttx/pull/1







*From:* David Sidrane [mailto:notificati...@github.com]
*Sent:* Saturday, December 21, 2019 3:42 AM
*To:* apache/incubator-nuttx
*Cc:* David Sidrane; Your activity
*Subject:* [apache/incubator-nuttx] imxrt fixes (#1)



In bringing up the NXP RDDRONE-FMURT6 these issues were discovered and
fixed.

· False detection

· No Detection I2C

· System lock up hang due to interrupt storm

Prior to this PR

NuttShell (NSH)

nsh>  i2cdetect -b 1

Scanning I2C bus: 1

 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

nsh>  i2cdetect -b 2

Scanning I2C bus: 2

 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 

Top Traces are the I2C IRQ, SPI IRQ and CPU IRQ,
Big Picture
[image: image]
<https://user-images.githubusercontent.com/1945821/71307341-c0d34700-23a1-11ea-8c5c-14727fceb0cd.png>
Focus on Storm
[image: image]
<https://user-images.githubusercontent.com/1945821/71307356-0263f200-23a2-11ea-8557-a49962a2dd3a.png>
The Storme rate.
[image: image]
<https://user-images.githubusercontent.com/1945821/71307363-1e679380-23a2-11ea-862f-0dd36cc39b21.png>

With this PR

NuttShell (NSH)

nsh>  i2cdetect -b 1

Scanning I2C bus: 1

 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 0e --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- 55 -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

nsh>  i2cdetect -b 2

Scanning I2C bus: 2

 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 1e --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

[image: image]
<https://user-images.githubusercontent.com/1945821/71307465-c3cf3700-23a3-11ea-91ad-d1e61b45ea53.png>
--
You can view, comment on, or merge this pull request online at:

  https://github.com/apache/incubator-nuttx/pull/1
Commit Summary

· imxrt:gpio Support readback on OUT GPIO

· imxrt:lpi2c imxrt_lpi2c_reset uses GPIO with SION

· imxrt:lpi2c ensure that on an error status reflects it.

· imxrt:lpi2c Fix interrupt storm on failed write.

· imxrt106x:pinout add ALT 8 GPIO_GPT2_COMPARE3 & fix
GPIO_GPT1_CAPTURE[1|2]
File Changes

· *M* arch/arm/src/imxrt/hardware/rt106x/imxrt106x_pinmux.h
<https://github.com/apache/incubator-nuttx/pull/1/files#diff-0> (5)

· *M* arch/arm/src/imxrt/imxrt_gpio.c
<https://github.com/apache/incubator-nuttx/pull/1/files#diff-1> (66)

· *M* arch/arm/src/imxrt/imxrt_lpi2c.c
<https://github.com/apache/incubator-nuttx/pull/1/files#diff-2> (220)
Patch Links:

· https://github.com/apache/incubator-nuttx/pull/1.patch

· https://github.com/apache/incubator-nuttx/pull/1.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/apache/incubator-nuttx/pull/1?email_source=notifications_token=AAO3BXOYD5KZJGGP5GB2ADLQZX6HHA5CNFSM4J6GW33KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ICD3JZA>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAO3BXK6MYSJ5NMZKDENOKTQZX6HHANCNFSM4J6GW33A>
.

RE: [incubator-nuttx] 05/05: imxrt106x:pinout add ALT 8 GPIO_GPT2_COMPARE3 & fix GPIO_GPT1_CAPTURE[1|2]

[David Sidrane]

Ut-oh It was not intended to be an abuse: This is how PR's or done all the
GH projects I am on as a commiter.
It is a branch in the repo so like you have always done with patches, you or
any of the PMC)can make change to it if need be.
It is PR to master in the same repo.

The process is simple: review it (fix it if need be), merge it and delete
the branch.


-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Saturday, December 21, 2019 4:41 AM
To: dev@nuttx.apache.org
Subject: Re: [incubator-nuttx] 05/05: imxrt106x:pinout add ALT 8
GPIO_GPT2_COMPARE3 & fix GPIO_GPT1_CAPTURE[1|2]

So I am confused.  It looks like you created a branch in the repository
and put all of you code there, bypassing patches and PRs.  This seems a
bit of an abuse of your privileges.  I though we agreed that all people,
including PPMC members and committers would have to follow the same work
flow.

True, we don't have a work flow in place yet, but all versions require
that changes be submitted as patches on d...@apache.org or as PRs.

I am not sure what do do with this now.  I am not going to touch it.
You may as well merge it to master too.

Greg

On 12/21/2019 4:56 AM, davi...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> davids5 pushed a commit to branch master_imxrt
> in repository https://gitbox.apache.org/repos/asf/incubator-nuttx.git
>
> commit 9b7afcdfe51bff99c35780d8cd1389ace8fc9318
> Author: David Sidrane 
> AuthorDate: Fri Dec 13 14:06:49 2019 -0800
>
>  imxrt106x:pinout add ALT 8 GPIO_GPT2_COMPARE3 & fix
> GPIO_GPT1_CAPTURE[1|2]
> ---
>   arch/arm/src/imxrt/hardware/rt106x/imxrt106x_pinmux.h | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/src/imxrt/hardware/rt106x/imxrt106x_pinmux.h
> b/arch/arm/src/imxrt/hardware/rt106x/imxrt106x_pinmux.h
> index 2e00ddb..add5479 100644
> --- a/arch/arm/src/imxrt/hardware/rt106x/imxrt106x_pinmux.h
> +++ b/arch/arm/src/imxrt/hardware/rt106x/imxrt106x_pinmux.h
> @@ -521,9 +521,9 @@
>   /* General Purpose Timer (GPT) */
>
>   #define GPIO_GPT1_CAPTURE1_1   (GPIO_PERIPH | GPIO_ALT4 |
> GPIO_PADMUX(IMXRT_PADMUX_GPIO_EMC_24_INDEX))
> -#define GPIO_GPT1_CAPTURE1_2   (GPIO_PERIPH | GPIO_ALT8 |
> GPIO_PADMUX(IMXRT_PADMUX_GPIO_B0_05_INDEX))
> +#define GPIO_GPT1_CAPTURE1_2   (GPIO_PERIPH | GPIO_ALT8 |
> GPIO_PADMUX(IMXRT_PADMUX_GPIO_B1_05_INDEX))
>   #define GPIO_GPT1_CAPTURE2_1   (GPIO_PERIPH | GPIO_ALT4 |
> GPIO_PADMUX(IMXRT_PADMUX_GPIO_EMC_23_INDEX))
> -#define GPIO_GPT1_CAPTURE2_2   (GPIO_PERIPH | GPIO_ALT8 |
> GPIO_PADMUX(IMXRT_PADMUX_GPIO_B0_06_INDEX))
> +#define GPIO_GPT1_CAPTURE2_2   (GPIO_PERIPH | GPIO_ALT8 |
> GPIO_PADMUX(IMXRT_PADMUX_GPIO_B1_06_INDEX))
>   #define GPIO_GPT1_CLK_1(GPIO_PERIPH | GPIO_ALT1 |
> GPIO_PADMUX(IMXRT_PADMUX_GPIO_AD_B0_13_INDEX))
>   #define GPIO_GPT1_COMPARE1_1   (GPIO_PERIPH | GPIO_ALT2 |
> GPIO_PADMUX(IMXRT_PADMUX_GPIO_EMC_35_INDEX))
>   #define GPIO_GPT1_COMPARE2_1   (GPIO_PERIPH | GPIO_ALT2 |
> GPIO_PADMUX(IMXRT_PADMUX_GPIO_EMC_36_INDEX))
> @@ -534,6 +534,7 @@
>   #define GPIO_GPT2_CLK_1(GPIO_PERIPH | GPIO_ALT7 |
> GPIO_PADMUX(IMXRT_PADMUX_GPIO_AD_B0_09_INDEX))
>   #define GPIO_GPT2_COMPARE2_1   (GPIO_PERIPH | GPIO_ALT1 |
> GPIO_PADMUX(IMXRT_PADMUX_GPIO_AD_B0_07_INDEX))
>   #define GPIO_GPT2_COMPARE3_1   (GPIO_PERIPH | GPIO_ALT1 |
> GPIO_PADMUX(IMXRT_PADMUX_GPIO_AD_B0_08_INDEX))
> +#define GPIO_GPT2_COMPARE3_2   (GPIO_PERIPH | GPIO_ALT8 |
> GPIO_PADMUX(IMXRT_PADMUX_GPIO_AD_B1_07_INDEX))
>
>   /* JTAG */
>
>

Re: Testing the new repository

[David Sidrane]

Opps That would be me. I am sorry I just saw this when I was sending the PR and 
the URL of the patch to the list.

I am happy to delete the branch and the PR if you like or we can use it to 
explore our new environment 
just let me know. (Or any PPMC can deleted it or push the merge button (choose 
from the green drop down))

However the changes to the IMXrt are critical so please insure the patch get 
applied/

more below

On 2019/12/21 11:30:27, Xiang Xiao  wrote: 
> Hi all,
> I would suggest that we still follow the original process before the
> new workflow is ready which mean that:
> 1.We post the patch to dev@nuttx.apache.org or
> 2.Send the pull request to https://github.com/apache/incubator-nuttx
> 3.Only Greg can commit the patch to apache/github repo
> I am seeing that PMC member is starting to create the branch in the
> offical repo as they see the needed.
> If we don't control this situation, we will have dozen(even hundred)
> of branches in the offical repo soon.

That is a good thing it means a project is health and being worked on but you 
right that the chaos has to be controlled. 

PR branches are (hopefully) very short lived as they are deleted when committed 
and discernible as a PR on github.

If we adopt the naming conventions of using pr in the branch name then the fact 
it is a PR is self referential in nay context command line/web/tablet

> These random named and created branches just confuse people who clone the 
> repo.

I agree with is in part, naming as in the OS is key

'master_imxrt' is too  master_imxrt
`stage` is too vague
`master-pr-imxrt_imxrt_fixes` - Says what it is: A PR against the branch master 
that fixes the imxrt.

master has always been master in the context of nuttx and as well on gitub as 
the default branch.

>  It's important to keep the original workflow and ensure all patches
> reviewed and committed by Greg before the automation tool is ready.
> 
> Thanks
> Xiang
> 
> 
> On Sat, Dec 21, 2019 at 5:59 AM Alan Carvalho de Assis
>  wrote:
> >
> > Hi Guys,
> >
> > We you can see the new repository is working fine.
> >
> > I submitted the i2C driver for STM32G070/NUCLEO-G070RB that was added
> > to bitbucket.
> >
> > As a rules of thumb, please don't commit directly to the "master".
> >
> > I created a brash called "stage" that we could use before merging in
> > to "master", this way other will have the chance to review.
> >
> > BR,
> >
> > Alan
> 

RE: [incubator-nuttx] 05/05: imxrt106x:pinout add ALT 8 GPIO_GPT2_COMPARE3 & fix GPIO_GPT1_CAPTURE[1|2]

[David Sidrane]

Ok. But that feels wrong. Aren't we going to have more than one set of eyes
on things? I do make a lot of mistakes.

I will let it sit a day and give a PMC member a chance to review it.

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Saturday, December 21, 2019 4:56 AM
To: dev@nuttx.apache.org
Subject: Re: [incubator-nuttx] 05/05: imxrt106x:pinout add ALT 8
GPIO_GPT2_COMPARE3 & fix GPIO_GPT1_CAPTURE[1|2]


> Ut-oh It was not intended to be an abuse: This is how PR's or done all the
> GH projects I am on as a commiter.
> It is a branch in the repo so like you have always done with patches, you
> or
> any of the PMC)can make change to it if need be.
> It is PR to master in the same repo.
>
> The process is simple: review it (fix it if need be), merge it and delete
> the branch.
>
Then you should do that.  I won't

Re: Test Repository

[David Sidrane]

Hi Justin,

Great points. See below

On 2019/12/21 00:42:58, Justin Mclean  wrote: 
> Hi,
> 
> You may need to think how this fits into releases. some things to consider:
> - Do you want the release to contain test information or not? A lot of Apache 
> project do include that but some don’t - it may be size dependant.
> - Do you wan users to be able to easy test releases? (Not providing test 
> infrastructure in the same releases may make that harder).
> - This is a common scenario, a user is on an old version and needs to test 
> it, the new testing repo has been updated to work with teh latest release, 
> how do they test it?
> 
> Thanks,
> Justin

>- This is a common scenario, a user is on an old version and needs to test it, 
>the new testing repo has been updated to work with teh latest release, how do 
>they test it?

The test repo has submudules to the nuttx and apps.

The master branch of testing is tied to master on apps and nuttx

The release branch(s) of testing is tied to the release branch(s)  on apps and 
nuttx

Then it always works.

However take nxtyle as an example.

We ask submitter to run nxtyle on code to make sure the submission abides by 
the NuttX coding standard.

If on day 94 the nxtyle finds an issue better then on day 12 of its life. A 
user may contribute a submission from a release that does not abides by the 
NuttX coding standard.

This can be mitigated by keeping the style tools in a separate repo and asking 
dev to always stay on master of that repo. It also enables CI to always use the 
best nxtyle we have. Thus keeping master properly formatted.

David

RE: Away for two weeks

[David Sidrane]

Enjoy!

-Original Message-
From: Justin Mclean [mailto:jus...@classsoftware.com]
Sent: Friday, December 20, 2019 5:07 PM
To: dev@nuttx.apache.org
Subject: Away for two weeks

H,

I’m off on a two week break, while I’ll have some time to answer questions,
where I'm going for the first week has limited internet access, no mobile
phone reception and no mains electricity. I may be able to check messages
once a day so I may be slow in responding to any questions that need mentor
help, hopefully your other mentors will be able to fill in as needed.

Thanks,
Justin

Re: [CALL for TOP Down workflow Requirements]

[David Sidrane]

Hi Brennan,

I agree with your reasoning and welcome the change, but let me expand on the 
initial reasoning. below.

On 2019/12/21 07:56:35, Brennan Ashton  wrote: 
> On Fri, Dec 20, 2019, 11:22 PM David Sidrane  wrote:
> 
> > All,
> >
> > Please help flesh this out.
> >
> > Proposed Workflow Requirements (REQ) and Derived Requirements (DREQ)
> >
> > REQ1) master is branches of apps and nuttx have to always build
> >   REQ1.1) ALL development work is done on branches.
> > DREQ1.1.1) master is branch protected prevention pushes to it.
> >
> > REQ2) git bisect shall always be able to build master of the project at
> > every commit.
> >  DREQ2.a) merges to master may use squash commits from a PR when
> > atomic commits are needed to insure REC2.
> >   DREQ2.b) merges to master may use rebase commits from a PR when NON
> > atomic commits will for insure REC2.
> >
> > REQ3) Submissions shall be PRs against branches typically master. But PR
> > shall be accepted against other branches.
> >   (i.e netlink_crypto)
> > REQ3.1) naming conventions shall reflect lineage:
> >REQ3.1.a) naming conventions of branches shall be in the form
> > _
> >master_pr-add_imxrt20, netlink_crypto-pr-bugfix_AES
> >REQ3.1.b) submissions affecting multiple repos shall use the same
> > branches name on all repos.
> >   DREQ3.1.b.1) CI shall test multiple repos by branch name
> >
> 
> I would like to loosen up the branch naming requirements, it will make it
> harder for people to contribute little things coming from the "GitHub"
> world, it's not something I see too much outside of the workplace. Also the
> generated branches on GitHub from a PR are using the ids.  I'm not trying
> to bring tooling in, but I think we should be aware of this and I think it
> brings minimal gain. I would be more in favor of the title or body of a PR
> doing the linking if we really need the standard to link things together.
> We need to be very sensitive to increases in complexity or we will loose
> new contributors.
> 
> 
> 
> >
> > REQ4) committer may collaborate on branches.
> >
> > REC5) While PR's are preferred, patches may be accepted.
> >DREC5.1) Committers receiving patches shall apply them to a new branch
> > (per REQ3) and open a PR.
> > REC5.1) Committers shall attribute work to the person submitting patch
> >
> > REC6) All PR requires a review.
> >  DREC6.1) the project shall publish a list of subject experts
> >   REC6.1) Request for review shall be made via email to subject experts or
> > PPMC.
> >   REC6.1.1)  Multiple reviewers shall be required on OS internals.
> >   REC6.1.2)  Multiple reviewers may be required on NON OS internals.
> >
> >
> > David
> 
> 
> The rest sounds good. I would say let's start minimal and work up if we
> find quality or complexity issues.
> 
> --Brennan
> 

The purpose was accommodating the "repos must be on the ASF infrastructure 
edict"[1] . 
Which I believe, please correct me if I am wrong, is pure git???

Therefore I was removing the dependency of githubs features on the work flow. 
The only way I know how to do this in pure git is: by tag, branch name or SHAL 

Since we can not use strike out in this environment:
Would you be ok with adding your edits in a diff like form?

I.e. 
 
-REQ3.1) naming conventions shall reflect lineage:
+REQ3.1) naming conventions may reflect lineage:

[1] mentor's email re:50 years support and how the internet changes

Also having to ignore github workfow for the sake of only being top down herein 
would not be my approach, but I am tying to accommodate everyone input. 

David

Re: Transferring Repositoies (Was Re: Masayuki Ishikawa added to NuttX committers)

[David Sidrane]

On 2019/12/20 21:09:18, Gregory Nutt  wrote: 
> [This conversation belongs on the dev list]
> 
> > Which way is the mirrors?
> >
> > I believe I read somewhere, it's apache --> github. But I could be wrong.
> 
> I recall Duo saying that you can set this up either way.
> 
> 
> 

PMC I would like to suggest the following be merged to bitbucket but not up 
streamed.

https://bitbucket.org/david_s5/nuttx/src/master_move_notice/

I will also share a suggestion that a college made once when we faced this same 
situation.

Hold on.cuz it sounds crazy.. you add the above notice with a link back one 
commit in the repo and `rm -fr` everything else in the repo this commit,

What this does prevent people from mistakenly using the repo and at the same 
time keeps all the ref to it valid, It is worth considering as it avoids "Oh 
the ... is a dead project" and hate mail.

Thoughts?

David

RE: Transferring Repositoies (Was Re: Masayuki Ishikawa added to NuttX committers)

[David Sidrane]

+1

-Original Message-
From: Brennan Ashton [mailto:bash...@brennanashton.com]
Sent: Friday, December 20, 2019 8:47 PM
To: dev@nuttx.apache.org
Subject: Re: Transferring Repositoies (Was Re: Masayuki Ishikawa added to
NuttX committers)

On Fri, Dec 20, 2019, 8:31 PM 张铎(Duo Zhang)  wrote:

> And I could help setting up the jenkins jobs on the asf infrastructure
> against github PRs to test them automatically. The website is
> https://builds.apache.org/ . Plan to work with Haitao together next week
> on
> this.
>

Could we please have a discussion on this before jumping into using
Jenkins.   I think there are some compelling reasons to use something like
GitHub Actions, especially with the ability to build on Linux, Windows, and
Mac easily. Also we can easily register outside runners which I would like
to wire up for a real device testing lab (I acquired hardware for the imxrt
family to do this prior to the Apache move)

--Brennan

>

Re: [CALL for TOP Down workflow Requirements]

[David Sidrane]

Thank you Nathan!

On 2019/12/22 06:01:55, Nathan Hartman  wrote: 
> On Sat, Dec 21, 2019 at 7:26 PM Gregory Nutt  wrote:
> 
> > Let me start by stating a few [obvious] objectives:
> > Keep things simple for those NuttX users who prefer to work with a zip’d
> > release.
> > provide best-practice tools and workflow to maximize productivity of
> > developers living on
> > the bleeding edge.
> > define a disciplined process that insures the continued quality of the
> > project.
> >
> > As we fill in the details, this discussion will naturally blend in
> > specifics of implementation
> > and tools — I expect “git” might come up in the discussions ;)
> 
> 
> At this point, much has been written in this and other threads.
> 
> Now I recommend that we should have a Confluence page where the information
> can be edited to make it:
> 
> * Plain English
> * Flow well
> * Readable
> * Coherent
> * Specific
> * Not assume knowledge
> * In one easy to find place
> 
> I say "I recommend that we should" instead of just going ahead and creating
> that Confluence page because I want to ensure that this happens with
> community agreement.
> 
> Rationale for creating the document: I don't want or expect anyone to
> memorize our workflow, nor to go digging all over the place to piece
> together what it is. I want it documented clearly so that veteran
> contributors and total newbies alike will be able to understand exactly
> what to do. I also want this documented for purpose of on-boarding future
> committers and so that committers will know what is expected of them
> whenever they commit. And furthermore I want it in a clear document that we
> can officially vote on to make it our "blessed" workflow, until such time
> as we decide to make changes and vote to update the "blessed" process.
> 
> The document should flow in a manner that makes information easy to find. I
> suggest to organize it as follows:
> 
> 1. Overview. This section defines "WHAT" the steps of the workflow are.
> This is a simple bulleted or numbered list. No rationale, no git jargon, no
> DevOps nonsense, just clear plain English. Where is the code. What basic
> steps take place to apply changes to it. Greg literally wrote this list a
> few emails ago and it contains 80% of what should be in that list. It needs
> minimal improvement.
> 
> 2. How To Submit Changes For Review. This section defines the "HOW" of the
> workflow for ANYONE who wants to get a change into NuttX, whether committer
> or not. Committers do not get to bypass this process. This section should
> document: How to obtain a copy of the code. What steps to take before
> beginning work on a change. Once you've made your change and want to
> contribute it, what steps to take to turn it into a PR or patch. How to
> submit the PR or patch to us? We should NOT assume knowledge. If a step
> requires using git, then give the exact git command followed by an
> explanation of every element of that command, so that anyone who knows how
> to enter a command in a terminal with zero prior knowledge of git will be
> able to understand exactly how to issue that git command and exactly what
> it will do. I want to make it straightforward and easy for a HARDWARE
> engineer to be able to submit changes.
> 
> 3. Criteria For Acceptance. This section defines what sorts of things
> committers will examine and verify before allowing changes into NuttX.
> First, the universal requirements that apply to all parts of NuttX. This
> includes INVIOLABLES, coding standard, rules that govern clean
> architecture, POSIX compliance, not breaking the build, etc. The word
> INVIOLABLES should be a link to that file. After the universal
> requirements, there should be requirements by area. Requirements for
> boards. Requirements for drivers. Requirements for the scheduler.
> Requirements for architectural support. Etc. All of the checks in this
> section can be performed manually by a committer for now. This section
> should be documented clearly and specifically enough that it can directly
> be used as the specification of automated checks to implement in a CI
> system.
> 
> 4. Reference For Committers. This section explains to committers how to
> carry out all the steps to process a proposed change from start to finish.
> "Start" means a patch or a PR arrived. If a patch, how to convert it into a
> PR. "Finish" can mean either applying the change to master, or reject the
> change / send it back to the submitter for additional work. And all steps
> in between. This section (item #4) is a continuation of item #2. Item #2
> explained how anyone submits a proposed change for review. Now we explain
> what happens next. Like item #2, we should NOT assume knowledge. If a step
> requires using git, then give the exact git command followed by an
> explanation of every element of that command. This is not excessive. This
> will help on-boarding of new committers as well as help veteran committers
> avoid mistakes.
> 
> 5. 

Re: [VOTE] - votes must say [VOTE]

[David Sidrane]

+1 binding

On 2019/12/22 15:13:03, David Sidrane  wrote: 
> All,
> 
> Let's dispense with the ALL ambiguity
> 
> We should assume if it does not say  [VOTE] it is not a vote?
> 
> David
> 
> 
> 
> -Original Message-
> From: Gregory Nutt [mailto:spudan...@gmail.com]
> Sent: Sunday, December 22, 2019 7:09 AM
> To: dev@nuttx.apache.org
> Subject: Re: Simple Workflow Proposal
> 
> Again, is this a formal vote?  it is not clear to me.  Did someone in
> the PPMC call a vote?  There is not [VOTE] in the message title?
> 
> Just  point of order which I do not know the answer too.  Brennan is not
> yet listed as a PPMC member or a as a committer (but he should be and,
> hopefully, will be). Can non-PPMC members calls votes that are binding
> on the PPMC? Just to be clear, I think that someone in the PPMC should
> call the vote with [VOTE] in the title so that is is clear if we are
> castubg a binding vote or not for something are not?  Or are we just
> agreeing in principle or not?
> 
> Are these binding votes?  We need to clarify what is going on.
> 
> I think we should stop the habit of using +1 just to indicate we agree
> with something and we need to enforce the use of [VOTE] in the title so
> that we know this is a binding vote.
> 
> On 12/22/2019 7:57 AM, Xiang Xiao wrote:
> > +1.
> > It's impotant to let people start the contribution.
> > The committer could/should do more work to ensure the correction in
> > review process before the automation tool is ready.
> >
> > Thanks
> > Xiang
> >
> > On Sun, Dec 22, 2019 at 8:57 PM David Sidrane  wrote:
> >> This works!
> >>
> >> On 2019/12/22 02:05:56, Brennan Ashton  wrote:
> >>> I really want to let people to contribute (myself included) ASAP so I
> >>> was
> >>> to propose this as an option to get going and can be amended later. I
> >>> know
> >>> it does not resolve all the issues, but offers what I think is a
> >>> reasonable
> >>> avenue to get started.
> >>>
> >>> Submit a PR on GitHub against master if it is approved by one commiter
> >>> (that did not propose it)
> >> This is key! We need the eyes (and possibly the hands)  of the subject
> >> matter experts, reviewing, commenting and possible fixing submissions.
> >>
> >>> it can be merged.  The approval is done via the
> >>> GitHub approval system.
> >> +1
> >>> A commiter may create a PR on behalf of a patch submitted to the mailing
> >>> list.
> >> +1
> >>> Commiters can ask for others to review or approve.  But at the end of
> >>> the
> >>> day they are the ones who approve and merge.
> >> +1
> >>> We can and should amend this later, it is likely not enough long term.
> >>>
> >>> Could people vote if they think this is fine to start. If you don't
> >>> agree
> >>> just note that and we can review where we are at.
> >>>
> >>> --Brennan
> >>>
> 

RE: [CALL for TOP Down workflow Requirements]

[David Sidrane]

+1

-Original Message-
From: Brennan Ashton [mailto:bash...@brennanashton.com]
Sent: Saturday, December 21, 2019 9:30 AM
To: dev@nuttx.apache.org
Subject: Re: [CALL for TOP Down workflow Requirements]

+1 to this.  No ci yet so everything "passes" and just gets the commiter
review.   We can define more later as needed

On Sat, Dec 21, 2019, 8:44 AM Xiang Xiao  wrote:

> Can we simplify the workflow to avoid creating so many temp branching
> in the official repo:
> 1.User submit PR against the master
> 2.Run style, build and test through CI
> 3.Review and comment PR by committer
> 4.Merge PR into master if all check pass
> User may have to repeat step 1 to 3 several time before PR finally accept.
> Note 1: step 2 may be done by committer manually before the tool is ready.
> Note 2: we can refine how many approvement is required before PR can be
> merge.
> If user send patch to dev@nuttx.apache.org instead, one of committer
> need convert the patch to PR by the same process too.
> If there has a big feature development, committer could create a
> branch for that after voting in dev list, but the same process should
> apply to this branch like master.
> Actually, this process is almost same as bitbucket or github, many
> developer is already familiar with it:
>
> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests
> The major difference from David's is that no any temp PR branch is
> created in the official repo.
>
> Thanks
> Xiang
>
> On Sat, Dec 21, 2019 at 8:36 PM Gregory Nutt  wrote:
> >
> > This is the mantra we must always follow "support what you users want."
> > Stay focused on the needs and convenience of the end-user.  Always good
> > advice.  If there are complexities dependencies, we should quantine
> > those complexities and dependencies inside the test architecture.  We
> > give the end-user maximal flexibility in all things.
> >
> > Businesses fail that don't listen tho their customers.  We will also
> > fail if we do not listen.
> >
> > On 12/21/2019 2:59 AM, Justin Mclean wrote:
> > > Hi,
> > >
> > >> The purpose was accommodating the "repos must be on the ASF
> infrastructure edict"[1] .
> > >> Which I believe, please correct me if I am wrong, is pure git???
> > > Most(?) use git, some also use svn, there might be a couple that still
> use cvs. Use of GitHub is not a requirement, but may be convenient.My
> advice be flexible and support what you users want.
> > >
> > > Thanks,
> > > Justin
> > >
> > >
> >
>

Re: Community

[David Sidrane]

On 2019/12/22 19:29:38, Gregory Nutt  wrote: 
> 
> > Don't feel bad if there is haggling. Any document, no matter who writes it
> > or how well, will need more work to fill in missing pieces, edit, etc., to
> > bring it to "shipping quality." I will try to help as much as I can in the
> > coming days, but as I said I'm really swamped right now.
> 
> But there are issues of trust related here.   I would not trust DavidS 
> to write objective work flow requirements now.  And I have no reason to 
> believe that he would trust me to do so either. Although I can say that 
> it would be my intention to produce a fair representation of the overall 
> discussion, my references would also be reflected in certain areas.
> 
> 
> 
Greg - please realize  that anything I (or you) suggest are just suggestion and 
examples. We are all going have to AGREE on what we will implement. Nothing bad 
is going to happen. None of it is in stone.

I would ask you to not couch thing in trust. It is not about trust. It is about 
experience.  You have created a wonderful gift to the world, in Nuttx. Using a 
"single commiter" model, a set of tools that you manage, and your own way of 
working.  You referred  to yourself as a Github  N00B. Other members on this 
team use github everyday. Their experience is what is of value here. I have not 
doubt that after you are a seasoned GH user of you would be able to craft the 
perfect GH work flow. 

My dad shared this with me once: If you can not dig a hole, do not stand over 
someone who is digging and tell them how to dig. Get the hell out of the way, 
let them do their job and bring them water.

Another pearl from him is: "You can't push a string"

Are you failure with the HAM Story?

[David Sidrane]

All,

This is one of my favorite Lessons that I learned... reposted from Private

Are you failure with the HAM Story?

A husband and his wife were in their kitchen. The husband was sitting at the
kitchen table reading the newspaper while his wife was preparing a ham for
dinner. The husband watched the wife cut off about one inch from either end
of the ham. He asked why she cut the end off, proclaiming “that’s a waste of
good ham!” She said “that’s the way my mom prepared the ham.” The husband
asked “why did your mom cut the ends off?” The wife didn’t know.

Later, the wife called her mom to find out why she cut the ends of the ham
off. Her mom said “because that was the way my mom prepared ham.”

The wife’s grandma passed away several years earlier, but her Grandpa was
still living. She called her Grandpa and asked “Grandpa, why did Grandma cut
the ends off of the ham?” He was silent as he thought for a moment. Then he
replied, “so the ham could fit in the baking pan.”

It relates nicely to https://en.wikipedia.org/wiki/Cargo_cult_programming

David


-Original Message-
From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
Sent: Friday, December 20, 2019 11:26 AM
To: priv...@nuttx.apache.org
Subject: Re: Email Attachments (Was Re: Masayuki Ishikawa added to NuttX
committers)

On Fri, Dec 20, 2019 at 12:31 PM Alan Carvalho de Assis
 wrote:
> What is the issue with .patch extension? This is default name
> generated by "git format-patch" command. Could you please explain the
> reason?

I don't know if there is an issue. I only mentioned it because I was
once told it makes it easier to review patches in some email clients:

On Wed Jul 31 11:11:11 CDT 2019 Daniel Shahaf wrote:
> By the way, in the future could you please name patches with a *.txt
> extension?  That should cause them to have a text/* MIME type which, in
> some email clients, makes the attachments easier to review.

Full message:
https://mailman.red-bean.com/pipermail/svnbook-dev/2019-July/017433.html

Nathan

Re: [DISCUSS - NuttX Workflow]

[David Sidrane]

What about the people who are just learning Nuttx? Simple is relative. I can 
see how a check out of one folder would make it hard in your setup and simple 
for the New folks is'nt that way we are here to grow the project?

BTW: your argument is solve by sub modules. You would just check out from nuttx 
repo  
It is also very helpful to have multiple remotes
nuttx
 nuttx ASF nuttx repo   
apps
  nat   nathan's apps repo 
  nuttx ASF apps repo 

git fetch nuttx
git log nuttx/apps - hmm that changed in make in afd890
git reset --hard nat/apps 
git cherry-pick afd890


On 2019/12/18 12:50:17, Nathan Hartman  wrote: 
> On Wed, Dec 18, 2019 at 5:46 AM David Sidrane  wrote:
> 
> > > 5 issue one pull request from your fork nuttx/apps to apache nuttx/apps
> > master branch
> >
> > Are you suggesting we have one repo NuttX with 2 folders apps and nuttx?
> >
> > That will simplify everything! - but I suspect we will receive STRONG
> > arguments against it.
> 
> 
> Yes, such as what will those of us do who have our own custom apps? Not
> everyone uses e.g. NSH. Some products are more deeply embedded than others.
> 
> i would oppose combining those two repos into one because i agree with the
> concept that we should not make the user's life harder for our convenience.
> 
> Most changes only affect only one repository or the other. For the much
> smaller number of changes that affect both, we should have some special
> handling.
> 
> Nathan
> 

RE: [DISCUSS - NuttX Workflow]

[David Sidrane]

I am not familiar with buildbot  ore this sort of setup so please forgive
for some simple minded questions.

Is this SW CI or HW CI or both?

How does the RPi/BBB/Laptop fit into the picture.

Any Pictures?

David

-Original Message-
From: Fabio Balzano [mailto:fa...@elfarolab.com]
Sent: Friday, December 20, 2019 5:22 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS - NuttX Workflow]

2 hours is a configured parameter, it is to allow burst of commits, it can
reduced to 0 if you need real time building, then the buildbot server can
also provision remote testing of the builds.

> On 20 Dec 2019, at 13:09, David Sidrane  wrote:
>
> Hi Fabio,
>
> What are the capabilities?
>
> It this 1 RPi/BBB per board nuttx board?
>
> David
>
> -Original Message-
> From: Fabio Balzano [mailto:fa...@elfarolab.com]
> Sent: Friday, December 20, 2019 5:06 AM
> To: dev@nuttx.apache.org
> Subject: Re: [DISCUSS - NuttX Workflow]
>
> Hello,
>
> yes the buildbot server is down, later today I will bring it up. Yes you
> can
> do remote builds using a RPI/BBB or similars or local builds performed by
> the server itself. I can setup and maintain the server for the Nuttx
> project
> in case you think it is useful.
>
> Thank you so much
> Fabio Balzano
>
>> On 20 Dec 2019, at 13:00, Alan Carvalho de Assis 
>> wrote:
>>
>> Hi David,
>>
>> Sorry for scolding you in public as well, but I think we don't need to
>> find guilt.
>>
>> So, I got the impression you were doing it to promote PX4 test
>> workflow as the best solution for all the NuttX issues.
>>
>> And although 300K drones are a lot, there are many commercial products
>> using NuttX. Many Sony audio recorders, Moto Z Snaps, Thermal
>> printers, etc. Probably we have products that overcome that number.
>>
>> I think recently Fabio changed the buildbot link. BTW I just remember
>> other alternative that Sebastien and I did about 3 years ago:
>>
>> https://bitbucket.org/acassis/raspi-nuttx-farm/src/master/
>>
>> The idea was to use low cost Raspberry PIs as a distributed build test
>> for NuttX. It worked fine! You just define a board file with the
>> configuration you want to test and it is done.
>>
>> BR,
>>
>> Alan
>>
>>> On 12/20/19, David Sidrane  wrote:
>>> Hi Alan,
>>>
>>> Sorry if  my intent was misunderstood. I am merely stating facts on were
>>> we
>>> are and how got there.I am not assigning blame. I am not forcing
>>> anything
>>> I
>>> am giving some examples of how we can make it the project complete and
>>> better. We can use all of it, some of it none of it. The is a group
>>> decision.
>>>
>>> Also Pleases do fill us in on where we can see the SW CI  & HW CI you
>>> mentioned. Do you have links maybe be we can use it now?
>>>
>>> Again Sorry!
>>>
>>> David
>>>
>>>> On 2019/12/20 11:44:23, Alan Carvalho de Assis 
>>>> wrote:
>>>> Hi David,
>>>>
>>>>> On 12/20/19, David Sidrane  wrote:
>>>>> Hi Nathan,
>>>>>
>>>>> On 2019/12/20 02:51:56, Nathan Hartman 
>>>>> wrote:
>>>>>> On Thu, Dec 19, 2019 at 6:24 PM Gregory Nutt 
>>>>>> wrote:
>>>>>>>>> ] A bad build system change can cause serious problems for a lot
>>>>>>>>> of
>>>>>> people around the world.  A bad change in the core OS can destroy the
>>>>>> good
>>>>>> reputation of the OS.
>>>>>>>> Why is this the case? Users should not be using unreleased code or
>>>>>>>> be
>>>>>> encouraged to use it.. If they are one solution is to make more
>>>>>> frequent
>>>>>> releases.
>>>>>>> I don't think that the number of releases is the factor.  It is time
>>>>>>> in
>>>>>>> people's hand.  Subtle corruption of OS real time behavior is not
>>>>>>> easily
>>>>>>> testing.   You normally have to specially instrument the software
>>>>>>> and
>>>>>>> setup a special test environment perhaps with a logic analyzer to
>>>>>>> detect
>>>>>>> these errors.  Errors in the core OS can persists for months and in
>>>>>>> at
>>>>>>> least one case I am aware of, years, until some sets up the correct
>

Re: [DISCUSS - NuttX Workflow]

[David Sidrane]

Hi Alan,

Sorry if  my intent was misunderstood. I am merely stating facts on were we are 
and how got there.I am not assigning blame. I am not forcing anything I am 
giving some examples of how we can make it the project complete and better. We 
can use all of it, some of it none of it. The is a group decision.

Also Pleases do fill us in on where we can see the SW CI  & HW CI you 
mentioned. Do you have links maybe be we can use it now?

Again Sorry!

David

On 2019/12/20 11:44:23, Alan Carvalho de Assis  wrote: 
> Hi David,
> 
> On 12/20/19, David Sidrane  wrote:
> > Hi Nathan,
> >
> > On 2019/12/20 02:51:56, Nathan Hartman  wrote:
> >> On Thu, Dec 19, 2019 at 6:24 PM Gregory Nutt  wrote:
> >> > >> ] A bad build system change can cause serious problems for a lot of
> >> people around the world.  A bad change in the core OS can destroy the
> >> good
> >> reputation of the OS.
> >> > > Why is this the case? Users should not be using unreleased code or be
> >> encouraged to use it.. If they are one solution is to make more frequent
> >> releases.
> >> > I don't think that the number of releases is the factor.  It is time in
> >> > people's hand.  Subtle corruption of OS real time behavior is not
> >> > easily
> >> > testing.   You normally have to specially instrument the software and
> >> > setup a special test environment perhaps with a logic analyzer to
> >> > detect
> >> > these errors.  Errors in the core OS can persists for months and in at
> >> > least one case I am aware of, years, until some sets up the correct
> >> > instrumented test.
> >>
> >> And:
> >>
> >> On Thu, Dec 19, 2019 at 4:20 PM Justin Mclean 
> >> wrote:
> >> > > ] A bad build system change can cause serious problems for a lot of
> >> people around the world.  A bad change in the core OS can destroy the
> >> good
> >> reputation of the OS.
> >> >
> >> > Why is this the case? Users should not be using unreleased code or be
> >> encouraged to use it.. If they are one solution is to make more frequent
> >> releases.
> >>
> >> Many users are only using released code. However, whatever is in "master"
> >> eventually gets released. So if problems creep in unnoticed, downstream
> >> users will be affected. It is only delayed.
> >>
> >> I can personally attest that those kinds of errors are extremely
> >> difficult
> >> to detect and trace. It does require a special setup with logic analyzer
> >> or
> >> oscilloscope, and sometimes other tools, not to mention a whole setup to
> >> produce the right stimuli, several pieces of software that may have to be
> >> written specifically for the test
> >>
> >> I have been wracking my brain on and off thinking about how we could set
> >> up
> >> an automated test system to find errors related to timing etc.
> >> Unfortunately unlike ordinary software for which you can write an
> >> automated
> >> test suite, this sort of embedded RTOS will need specialized hardware to
> >> conduct the tests. That's a subject for another thread and i don't know
> >> if
> >> now is the time, but I will post my thoughts eventually.
> >>
> >> Nathan
> >>
> >
> > From the proposal
> >
> > "Community
> >
> > NuttX has a large, active community.  Communication is via a Google group at
> > https://groups.google.com/forum/#!forum/nuttx where there are 395 members as
> > of this writing.  Code is currently maintained at Bitbucket.org at
> > https://bitbucket.org/nuttx/.  Other communications are through Bitbucket
> > issues and also via Slack for focused, interactive discussions."
> >
> >
> >> Many users are only using released code.
> >
> > Can we ask the 395 members?
> >
> > I can only share my experience with NuttX since I began working on the
> > project in 2012 for multiple companies.
> >
> > Historically (based on my time on the project) releases - were build tested
> > - by this I mean that the configurations were updated and the thus created a
> > set of "Build Test vectors" BTV. Given the number of permutations solely
> > based on the load time of
> > (http://nuttx.org/doku.php?id=documentation:configvars) with 95,338 CONFIG_*
> > hits. Yes there are duplicates on the page and dependencies. This is just
> > meant to give a number of bits
> >
&g

Re: [DISCUSS - NuttX Workflow]

[David Sidrane]

Hi Nathan,

You Rock!

On 2019/12/20 05:31:37, Nathan Hartman  wrote: 
> On Thu, Dec 19, 2019 at 4:40 PM David Sidrane  wrote:
> > > Changes to code in MCU architectural support, board support, or features
> > > in the periphery of the OS should be at the discretion of the
> > > committer. Committers should use their best judgment and are
> > > encouraged to discuss anything they're not sure about. But these
> > > changes don't require as much oversight. These changes are much more
> > > limited in their exposure. They are usually developed by someone to
> > > scratch their own itch. Also these are allowed to be feature-
> > > incomplete: e.g., it is okay to have partial board support.
> >
> > I do not agree. MCU and board changes need better scrutiny for many reasons,
> > here are some:
> >
> > 1) Proper patterns applied. This gets misses a lot - consider the "ifdef
> > rash" and missed invilotes
> > 2) Proper scoping - this just happened in imxrt
> > 3) They still can break the build.
> > 3) They still can ruin the OS's reputation.
> > 4) This is where HW background is needed.
> >
> > You may want to consider separate levels of scrutiny for MCU's than boards.
> 
> Acknowledged.
> 
> The issue with boards and MCUs is that the pool of contributors for
> these areas is much thinner than the pool of contributors for some of
> the more heavily exercised areas.
> 
> Now, I can see where a company that produces a board -- and wants to
> provide full NuttX support for it in order to sell those boards --
> could pay engineers to develop FULL tested and characterized support
> for the board and all its features.
> 
> But, if it's a volunteer like me, I would likely implement support for
> the parts I'm going to use. It's a "scratch your own itch" type of
> development. Although this is "incomplete," I would greatly prefer to
> have it contributed to NuttX, over rejecting it due to incompleteness,
> because it reduces effort for the next person who wants to use that
> board, even if they need to implement support for a missing feature.
> It's better to start with partial support and implement the extra part
> you need, then to start from zero.
> 
> Now, I agree that we need to check for proper patterns, proper
> scoping, and unbroken build. But we can't necessarily have PMC members
> testing changes to boards because they may not have the board. Also,
> testing changes may require a whole hardware test setup with
> oscilloscope / logic analyzer and we cannot expect PMC members to
> spend that much time testing a change. It will never get voted on and
> people will become discouraged and stop contributing. So, we must have
> a certain amount of trust that the person contributing changes is
> doing so in good faith. Perhaps we need a PMC vote, or, say, two non-
> PMC committers to agree that changes to board support follow the code
> conventions and rules, but their +1 doesn't have to imply that they
> have the hardware and actually tested the change. As long as it
> follows basic rules and seems legit, it should be committed.
> 

Right!  Boards are secondary - your itch, your blood if you scratch it wrong.

> As for protecting the OS's reputation, I think that each board should
> have some sort of "Status" score:
>

Yes! +(1.0/0.0) more then 18billion :)
 
> * Boards with complete support that are widely exercised and known
>   to work correctly out of the box could be given a "Tier 1" status.
>   Recommended if you just want to focus on your application and have
>   all the hardware details taken care of for you.
> 
> * Boards with less support and testing could be categorized as
>   "Tier 2" status, meaning that NuttX's support for them might be
>   fine for some applications but some board features may be
>   unsupported, incomplete, or not well-exercised. Recommended for
>   the hardware savvy who don't mind if they have to fix a few issues
>   to finish their project.
> 
> * "Tier 3" could mean implementation in progress and many features
>   are missing or buggy. Recommended for those who want to hack on
>   support for the board.
> 
> How to arrive at such a status score? This could be problematic, since
> not all of us own every single board in NuttX, and even if we did, we
> could never volunteer the time that it would take to characterize and
> test every board and all its features with NuttX. So we may have to
> rely on the word of the implementer and community members who happen
> to use a particular board, or we could consider factors like the
> number of contributors who have worked on a board, the num

Re: [DISCUSS - NuttX Workflow]

[David Sidrane]

Hi Nathan,

On 2019/12/20 02:51:56, Nathan Hartman  wrote: 
> On Thu, Dec 19, 2019 at 6:24 PM Gregory Nutt  wrote:
> > >> ] A bad build system change can cause serious problems for a lot of
> people around the world.  A bad change in the core OS can destroy the good
> reputation of the OS.
> > > Why is this the case? Users should not be using unreleased code or be
> encouraged to use it.. If they are one solution is to make more frequent
> releases.
> > I don't think that the number of releases is the factor.  It is time in
> > people's hand.  Subtle corruption of OS real time behavior is not easily
> > testing.   You normally have to specially instrument the software and
> > setup a special test environment perhaps with a logic analyzer to detect
> > these errors.  Errors in the core OS can persists for months and in at
> > least one case I am aware of, years, until some sets up the correct
> > instrumented test.
> 
> And:
> 
> On Thu, Dec 19, 2019 at 4:20 PM Justin Mclean 
> wrote:
> > > ] A bad build system change can cause serious problems for a lot of
> people around the world.  A bad change in the core OS can destroy the good
> reputation of the OS.
> >
> > Why is this the case? Users should not be using unreleased code or be
> encouraged to use it.. If they are one solution is to make more frequent
> releases.
> 
> Many users are only using released code. However, whatever is in "master"
> eventually gets released. So if problems creep in unnoticed, downstream
> users will be affected. It is only delayed.
> 
> I can personally attest that those kinds of errors are extremely difficult
> to detect and trace. It does require a special setup with logic analyzer or
> oscilloscope, and sometimes other tools, not to mention a whole setup to
> produce the right stimuli, several pieces of software that may have to be
> written specifically for the test
> 
> I have been wracking my brain on and off thinking about how we could set up
> an automated test system to find errors related to timing etc.
> Unfortunately unlike ordinary software for which you can write an automated
> test suite, this sort of embedded RTOS will need specialized hardware to
> conduct the tests. That's a subject for another thread and i don't know if
> now is the time, but I will post my thoughts eventually.
> 
> Nathan
> 

>From the proposal

"Community

NuttX has a large, active community.  Communication is via a Google group at 
https://groups.google.com/forum/#!forum/nuttx where there are 395 members as of 
this writing.  Code is currently maintained at Bitbucket.org at 
https://bitbucket.org/nuttx/.  Other communications are through Bitbucket 
issues and also via Slack for focused, interactive discussions."


> Many users are only using released code.

Can we ask the 395 members?

I can only share my experience with NuttX since I began working on the project 
in 2012 for multiple companies.

Historically (based on my time on the project) releases - were build tested - 
by this I mean that the configurations were updated and the thus created a set 
of "Build Test vectors" BTV. Given the number of permutations solely based on 
the load time of (http://nuttx.org/doku.php?id=documentation:configvars) with 
95,338 CONFIG_* hits. Yes there are duplicates on the page and dependencies. 
This is just meant to give a number of bits 

The total space is very large

The BTV space was very sparse coverage. 

IIRC Greg gave the build testing task a day of time. It was repeated after 
errors were found.  I am not aware of any other testing. Are you?

There were no Release Candidate (rc) nor alpha nor beta test that ran this code 
one real systems and very little, if any Run Test Vectors (RTV) - I have never 
seen a test report - has anyone?

One way to look at this is Sporadic Integration. (SI) with limited BTV and 
minimal RTV.  Total Test Vector Coverage TTVC = BTV + RTV;  The ROI of  way of 
working, from a reliability perspective was and is very small.  

A herculean effort Greg's part with little return: We released code with many 
significant and critical errors in it. See the ReleaseNotes and the commit log.

Over the years Greg referred to TRUNK (yes it was on SVN) and master as his 
"own sandbox" stating is should not be considered stable or build-able. This is 
evident in the commit log. 

I have personally never used a release from a tarball. Given the above why 
would I? It is less stable then master at TC = N 
(https://www.electronics-tutorials.ws/rc/rc_1.html) where N Is some number of 
days after a release. - unfortunately based on the current practices (a very 
unprofessional workflow)  N is also dictated by when apps and nuttx actually 
building for a given target's set of BTV.

With the tools and resources that exist in our work today, Quite frankly: This 
unacceptable and is an embarrassment. 

I suspect this is why there is a Tizen. The modern era - gets it. (Disclaimer I 
am an old dog - I am learning to get it)

--- 

RE: [DISCUSS - NuttX Workflow]

[David Sidrane]

Hi Fabio,

What are the capabilities?

It this 1 RPi/BBB per board nuttx board?

David

-Original Message-
From: Fabio Balzano [mailto:fa...@elfarolab.com]
Sent: Friday, December 20, 2019 5:06 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS - NuttX Workflow]

Hello,

yes the buildbot server is down, later today I will bring it up. Yes you can
do remote builds using a RPI/BBB or similars or local builds performed by
the server itself. I can setup and maintain the server for the Nuttx project
in case you think it is useful.

Thank you so much
Fabio Balzano

> On 20 Dec 2019, at 13:00, Alan Carvalho de Assis 
> wrote:
>
> Hi David,
>
> Sorry for scolding you in public as well, but I think we don't need to
> find guilt.
>
> So, I got the impression you were doing it to promote PX4 test
> workflow as the best solution for all the NuttX issues.
>
> And although 300K drones are a lot, there are many commercial products
> using NuttX. Many Sony audio recorders, Moto Z Snaps, Thermal
> printers, etc. Probably we have products that overcome that number.
>
> I think recently Fabio changed the buildbot link. BTW I just remember
> other alternative that Sebastien and I did about 3 years ago:
>
> https://bitbucket.org/acassis/raspi-nuttx-farm/src/master/
>
> The idea was to use low cost Raspberry PIs as a distributed build test
> for NuttX. It worked fine! You just define a board file with the
> configuration you want to test and it is done.
>
> BR,
>
> Alan
>
>> On 12/20/19, David Sidrane  wrote:
>> Hi Alan,
>>
>> Sorry if  my intent was misunderstood. I am merely stating facts on were
>> we
>> are and how got there.I am not assigning blame. I am not forcing anything
>> I
>> am giving some examples of how we can make it the project complete and
>> better. We can use all of it, some of it none of it. The is a group
>> decision.
>>
>> Also Pleases do fill us in on where we can see the SW CI  & HW CI you
>> mentioned. Do you have links maybe be we can use it now?
>>
>> Again Sorry!
>>
>> David
>>
>>> On 2019/12/20 11:44:23, Alan Carvalho de Assis 
>>> wrote:
>>> Hi David,
>>>
>>>> On 12/20/19, David Sidrane  wrote:
>>>> Hi Nathan,
>>>>
>>>> On 2019/12/20 02:51:56, Nathan Hartman 
>>>> wrote:
>>>>> On Thu, Dec 19, 2019 at 6:24 PM Gregory Nutt 
>>>>> wrote:
>>>>>>>> ] A bad build system change can cause serious problems for a lot
>>>>>>>> of
>>>>> people around the world.  A bad change in the core OS can destroy the
>>>>> good
>>>>> reputation of the OS.
>>>>>>> Why is this the case? Users should not be using unreleased code or
>>>>>>> be
>>>>> encouraged to use it.. If they are one solution is to make more
>>>>> frequent
>>>>> releases.
>>>>>> I don't think that the number of releases is the factor.  It is time
>>>>>> in
>>>>>> people's hand.  Subtle corruption of OS real time behavior is not
>>>>>> easily
>>>>>> testing.   You normally have to specially instrument the software
>>>>>> and
>>>>>> setup a special test environment perhaps with a logic analyzer to
>>>>>> detect
>>>>>> these errors.  Errors in the core OS can persists for months and in
>>>>>> at
>>>>>> least one case I am aware of, years, until some sets up the correct
>>>>>> instrumented test.
>>>>>
>>>>> And:
>>>>>
>>>>> On Thu, Dec 19, 2019 at 4:20 PM Justin Mclean
>>>>> 
>>>>> wrote:
>>>>>>> ] A bad build system change can cause serious problems for a lot
>>>>>>> of
>>>>> people around the world.  A bad change in the core OS can destroy the
>>>>> good
>>>>> reputation of the OS.
>>>>>>
>>>>>> Why is this the case? Users should not be using unreleased code or
>>>>>> be
>>>>> encouraged to use it.. If they are one solution is to make more
>>>>> frequent
>>>>> releases.
>>>>>
>>>>> Many users are only using released code. However, whatever is in
>>>>> "master"
>>>>> eventually gets released. So if problems creep in unnoticed,
>>>>> downstream
>>>>> users will be affect

RE: [DISCUSS - NuttX Workflow]

[David Sidrane]

>what advantage does in fact the submodule method bring?
See below

>Even with a hat repository that contains two submodules (apps and nuttx),
>you
>will have to send separate pull requests for each submodule, right?

Yes. But they com nit in 1 Atomic operation.


Submodules 101

This example is with write access on the repo - for committers

git clone  NuttX
cd NuttX
git checkout master
git submodule sync --recursive && git submodule update --init --recursive

git checkout -b master_add_tof_driver

cd nuttx
git checkout -b master_add_tof_driver

#work and commit - rebase on self and remove drabble.
rebase -i master
#reorder, squash and fixup the commits (learn about mv-changes is your
friend) - you will look organized.

cd apps
git checkout -b master_add_tof_driver

#work and commit - rebase on self and remove cruft and noise.
rebase -i master
#reorder, squash and fixup the commits (learn about mv-changes it is your
friend) - you will look organized.

#Build and test locally.
## AOK

cd apps
git push origin master_add_tof_driver

cd nuttx
git push origin master_add_tof_driver

cd .. (NuttX)
git add nuts apps
git commit "Update NuttX with TOF driver"

git push origin master_add_tof_driver

Ok so now (shal simplified to compare them)

NuttX master shal  point to
  \nuttx master shal 
  \apps master shal 

NuttX master_add_tof_driver 
  \nuttx master shal aaa
  \apps master shal bbb

merge PR from apps to master apps
merge PR from nuttx to master nuttx

NuttX master shal  point to (still builds and runs)
  \nuttx master shal 
  \apps master shal 

But the branch master of the submodules

  \nuttx master shal aaa
  \apps master shal bbb


merge PR from NuttX to master NuttX (atomic replacement)
NuttX master shal z point to
  \nuttx master shal aaa
  \apps master shal bbb



-Original Message-
From: Sebastien Lorquet [mailto:sebast...@lorquet.fr]
Sent: Wednesday, December 18, 2019 5:52 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS - NuttX Workflow]

Wait,

what advantage does in fact the submodule method bring?

Even with a hat repository that contains two submodules (apps and nuttx),
you
will have to send separate pull requests for each submodule, right?

Sebastien

Le 18/12/2019 à 14:40, Gregory Nutt a écrit :
> On 12/18/2019 4:23 AM, David Sidrane wrote:
>> That is precisely what submodules do:submodules aggregate on a single
>> SHAL N
>> repositories.
>>
>> The problem is: How to have atomic checkout of the correct configuration
>> with
>> out a temporal shift?
>>
>> Please describe how you would do this. Give detailed steps.
>
> I don't see any difference in versioning with submodules.  You have to
> explicitly state the UUID you are using in the submodule (unless there is
> a
> GIT sub-module trick I don't know).
>
> So how would you checkout the correct configuration with sub-modules.
> Seems
> to me that it is the same issue.
>
> I would vote about 18billion minus for this change.  But architecture
> designs
> are not justified by blantant expediency.
>
> Let's not go this way.
>
>

RE: [DISCUSS - NuttX Workflow]

[David Sidrane]

Hi Nathan,

Great list!

I can +1 on most of them, but isn't correct that the PPMC will need to all
agree on these?

> When they wish to contribute, they can do so:
> * Via a pull request
> * Via a patch transmitted to us by some method

Is this an ASF edict?

> Regardless of the method, we would convert the pull request and/or
> patch into a form that is useful for us. For example, if we work with
> pull requests and we are given a patch, we convert the patch into a
> pull request.

Where is the ability to have group a review? How is it done?

> Contributions may be based on:
> * Master.
> * Or the latest release. When contributions are based on the latest
> release, we should rebase them onto master.

What If the fix on master? Would it need to be backported to the release?
How do you see the decision made on backports and who does this?

David


-Original Message-
From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
Sent: Wednesday, December 18, 2019 8:56 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS - NuttX Workflow]

On Wed, Dec 18, 2019 at 11:18 AM Gregory Nutt  wrote:
> Requirements specification is a top-down activity.  It is only driven by
> end users needs and project objects.  NOT by implementation.  That is
> the nature of System Engineering: top-down

Just throwing some thoughts out here as a starting point for that
top-down discussion:

Users of NuttX can:
* Use NuttX with our Apps
* Use NuttX by itself and provide their own Apps

For the toolchain, they can:
* Use the toolchains we provide with buildroot
* Use their own toolchains

They can get NuttX and/or apps:
* From Git
* From source release tarballs

If getting from Git, they can:
* Live on the bleeding edge with Master
* Work from a branch or tag for more stability

When they wish to contribute, they can do so:
* Via a pull request
* Via a patch transmitted to us by some method

Regardless of the method, we would convert the pull request and/or
patch into a form that is useful for us. For example, if we work with
pull requests and we are given a patch, we convert the patch into a
pull request.

Contributions may be based on:
* Master.
* Or the latest release. When contributions are based on the latest
release, we should rebase them onto master.

RE: [DISCUSS - NuttX Workflow]

[David Sidrane]

Agreed!

Gosh I am hoping I am not talking down to people. I just remember my
learning curve with git. If we are continuing to use git and I assume we
are: My comments are meant to help people that do not understand how to use
git for the process and evaluate what they will have to do if we choose a
specific implementation.

Would you please layout the step for using patches and educate us on that
process as well


David

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Wednesday, December 18, 2019 8:19 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS - NuttX Workflow]


>> What about the people who are just learning Nuttx? Simple is
>> relative. I can see how a check out of one folder would make it hard
>> in your setup and simple for the New folks is'nt that way we are here
>> to grow the project?
> users should not need to learn details of the workflow
>> BTW: your argument is solve by sub modules. You would just check out
>> from nuttx repo
>> It is also very helpful to have multiple remotes
>> nuttx
>>   nuttx ASF nuttx repo
>> apps
>>nat   nathan's apps repo
>>nuttx ASF apps repo
>>
>> git fetch nuttx
>> git log nuttx/apps - hmm that changed in make in afd890
>> git reset --hard nat/apps
>> git cherry-pick afd890
>>
> Please no... save the github chatter for another day, another thread.
> I refuse to even look at that

Requirements specification is a top-down activity.  It is only driven by
end users needs and project objects.  NOT by implementation.  That is
the nature of System Engineering: top-down

Design for an implementation, on the other hand, is usually a bottoms-up
activity:  You implement the lowest level foundations of the system and
build on top of that to complete the full functional requirements.

This is extreme bad, bad engineering to drive system functional
requirements base on pre-determined implementation of the lowest level.
It is a terrible, unprofessional practice.  We need to keep proper
top-down system engineering practices, and not get derailed by this low
level stuff.

We do indeed need pick the nicest dress from show room window based upon
what we really want, not be rummaging through the bargain for the
cheapest thing.

Let's get profressional!

Greg

RE: [DISCUSS - NuttX Workflow]

[David Sidrane]

>(unless there is a GIT sub-module trick I don't know)

I believe this to be == TRUE. See the steps - try them then you will
understand.


-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Wednesday, December 18, 2019 5:40 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS - NuttX Workflow]

On 12/18/2019 4:23 AM, David Sidrane wrote:
> That is precisely what submodules do:submodules aggregate on a single SHAL
> N repositories.
>
> The problem is: How to have atomic checkout of the correct configuration
> with out a temporal shift?
>
> Please describe how you would do this. Give detailed steps.

I don't see any difference in versioning with submodules.  You have to
explicitly state the UUID you are using in the submodule (unless there
is a GIT sub-module trick I don't know).

So how would you checkout the correct configuration with sub-modules.
Seems to me that it is the same issue.

I would vote about 18billion minus for this change.  But architecture
designs are not justified by blantant expediency.

Let's not go this way.

RE: [DISCUSS - NuttX Workflow]

[David Sidrane]

The 2 and 3 is to contrast HARD against EASY. This is so ALL of us can
realize we are not suggesting doing what is expedient*, What is being
suggested is doing what is right. I am having a really hard time to get you
to see this is not about EASY. It is subtle.

>I don't know if my understanding of the proposal is correct (I think
I've confused 2 and 3 a couple of times).  But I can't imagine a problem
with the testing/ repository that holds sub-modules.  The user would not
be impacted by such a thing in any.

Yes they are an end-user needs to pull nuttx and apps at any instant in time
and have them be in sync.

*there is no intent to violate the inviolate

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Wednesday, December 18, 2019 6:06 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS - NuttX Workflow]

So I hope that we do not go to far down the github rabbit hole.  At this
level.  Everytime we have tried to address and agree to the functional
work flow, we get derailed by github technical implementation details.
I think this discussion is relevant still, but we are on edge losing
focus ont he functional workflow and talking only about github
implementation (and have crossed the edge at times).

> what advantage does in fact the submodule method bring?
>
> Even with a hat repository that contains two submodules (apps and nuttx),
> you
> will have to send separate pull requests for each submodule, right?

There are three different concepts being discussed here that I think we
should separate.  I know that I get confused about which is which.

 1. Two repositories apps/ and nuttx/ -- GOOD
 2. One respository with apps/ and nuttx/ as folders -- VERY, VERY BAD
 3. Three repositories, apps/, nuttx/ and, say, testing/.  Where testing
has the apps/and nuttx/ as submodules -- WORTH CONSIDERING

Number 3 would simply be a mechanization to support the workflow.  The
end user would never clone it or need ever be concerned about it in any
way.  From the end-user point of view apps/ and nuttx/ are the only
repositories.

I don't know if my understanding of the proposal is correct (I think
I've confused 2 and 3 a couple of times).  But I can't imagine a problem
with the testing/ repository that holds sub-modules.  The user would not
be impacted by such a thing in any.

If there is no user impact and no smearing of architectural entities,
then I retract bad things I said about sub-modules in any previous
discussion.

Greg

RE: [DISCUSS - NuttX Workflow]

[David Sidrane]

Greg,

Where do you see any reference to github (In a url as an example?)

This is all pure git.

Are we going to continue using git?


David
-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Wednesday, December 18, 2019 8:07 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS - NuttX Workflow]


> What about the people who are just learning Nuttx? Simple is relative. I
> can see how a check out of one folder would make it hard in your setup and
> simple for the New folks is'nt that way we are here to grow the project?
users should not need to learn details of the workflow
> BTW: your argument is solve by sub modules. You would just check out from
> nuttx repo
> It is also very helpful to have multiple remotes
> nuttx
>   nuttx ASF nuttx repo
> apps
>nat   nathan's apps repo
>nuttx ASF apps repo
>
> git fetch nuttx
> git log nuttx/apps - hmm that changed in make in afd890
> git reset --hard nat/apps
> git cherry-pick afd890
>
Please no... save the github chatter for another day, another thread.  I
refuse to even look at that

Attachment test Photo

[David Sidrane]

Got it!



How about this.

Never got your GitHub invitation? Visit github.com/apache to see if you
have an invitation pending.
 Apache Account:Authed

Welcome back, David!
*Not David? Log out
 then!*
 GitHub Account:Authed

You are currently authed as davids5 on GitHub. (not the right account? Reset
your GitHub info then
.)
 MFA Status:MFA ENABLED

Write access granted





-Original Message-
From: Alan Carvalho de Assis [mailto:acas...@gmail.com]
Sent: Friday, December 20, 2019 9:57 AM
To: dev
Subject: [PATCH] This is a test! Please DON'T commit!



Testing attachments.



Greg, please confirm you can receive attachments.



BR,



Alan

Re: [PATCH] This is a test! Please DON'T commit!

[David Sidrane]

https://lists.apache.org/list.html?dev@nuttx.apache.org

LOL - the list does list nor archive attachments. 

On 2019/12/20 17:56:42, Alan Carvalho de Assis  wrote: 
> Testing attachments.
> 
> Greg, please confirm you can receive attachments.
> 
> BR,
> 
> Alan
> 

RE: Single Committer

[David Sidrane]

Hi Ben,

If you deep dive into this you will see that perforce is a SCM[1] that
predates git. The tools are to perforce as, github is to git.

[1] software configuration management (SCM or S/W CM)

David

-Original Message-
From: Disruptive Solutions [mailto:disruptivesolution...@gmail.com]
Sent: Monday, December 23, 2019 11:03 PM
To: dev@nuttx.apache.org
Subject: Re: Single Committer

A platform like this could help? Samsung seems to use it? Does Apache has
something like this “Helix Core” and “Swarm” ??

https://www.perforce.com/products/helix-swarm

Benefit drom these ideas? And you could start with 1 commiter and scale up
later. The way of working will be getting more clear and get to the
“standards” Greg sees??


Verstuurd vanaf mijn iPhone

> Op 24 dec. 2019 om 06:07 heeft Nathan Hartman 
> het volgende geschreven:
>
> On Mon, Dec 23, 2019 at 7:51 PM Gregory Nutt  wrote:
>>
>> Recent events have made me reconsider some decisions I made.  I threw
>> off the single committer mantle when I saw the abuse of privilege in the
>> repositories.  If the PPMC agrees to it, I will take up that role again.
>>
>> But let's be frank.  Here is what I think that means:
>>
>>  * I would be sole committer of changes.  The repositories would have
>>to be treated as read-only just as back in the Bitbucket days.
>>  * I would grandfather in the i.MXRT changes.
>>  * I will decline all workflow related changes until workflow
>>requirements are established (that is my only real motivation for
>>suggesting this:  To make certain that we have proper requirements
>>in place before we accept PX4 workflow into our repositories.  We
>>need to do this right and I am willing to protect the repositories
>>until the workflow requirements are established.  I expect that to
>>take about two weeks.)
>>  * I would create a dev branch and expect all PRs to be against that
>>dev branch.
>>  * As soon as the PPMC is confident that it has the processes in place
>>to handle the commit workload I will gladly relinquish this role.
>>  * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
>>expedite the avalanche of commits expected after the holidays.
>>
>> If any of this concerns people, please "Just Say No."  I am not married
>> to the idea and I am not forcefully advocating it.  This is what people
>> wanted me to do a few days ago and if I can protect our right to define
>> the workflow, then I will do it.  For me it is a sacrifice that I would
>> take with no pleasure in.
>>
>> Pros:  This will provide project continuity until the PPMC is fully
>> functional.  Having workflow requirements will be a huge step in that
>> direction.  People stressed about the commit process can relax with
>> confidence.  This will protect the code base from premature work flow
>> changes until we have an understanding of what we want.  No harm is done
>> by deferring workflow changes until we as a team are prepared to deal
>> with them.
>>
>> Cons:  This is not the Apache way.  People who are trying to bulldoze
>> the PX4 work flow into the repositories will hate the idea.  Mentors
>> will hate the idea.  An approach more consistent with the Apache way
>> would just be to let the chaos prevail.  That is fine with me too as
>> long as we do not let PX4 advocates take away our group right to define
>> our own workflow.  We can still just put all workflow changes on hold
>> until we have the requirements in hand.
>>
>> I am not pushing anything.  Think about it and let me know what you
>> would like to do.
>
> I agree with this because it is premature to change the way we work
> before there is a documented workflow that helps us understand what to
> do.
>
> Over the next two weeks, we should focus on designing the top-down
> workflow. It doesn't have to be final and it doesn't have to be
> perfect. We can improve it over time. But right now it's not ready,
> so I appreciate Greg's offer to do that, while the workflow is prepared.
>
> Thanks to Greg and everyone,
> Nathan

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane]

Hi Xiang,

On 2019/12/25 05:36:14, Xiang Xiao  wrote: 
> Yes, I agree that we shouldn't make the workflow too hard to scare
> people for contribution.
> NuttX isn't a new project, it's open source for more than ten years
> and has a mature workflow, the whole community is already familiar
> with it.
> Let me summary the current workflow:
> 1.User send patch against master to
> https://groups.google.com/forum/#!forum/nuttx or
> 2.User send PR against master to https://bitbucket.org/nuttx/nuttx/src/master/
> 3.Greg review and merge the change to master(with some modification if needed)
> 4.Greg make a official release and create a tag to mark the point
> every two(or three?) months
> To "be apache way", the required change is only item 3&4: all
> committer need involve the reviewing and release process.
> So, I suggest that we adapter the current workflow with as minimal
> changes as possible:

The above workflow was in support of a BD model who preferred to use patches 
and refused to use github. (no disrespect intended). The value it added was 
incredible quality (but in reality only in the areas  important to the BD). At 
the same time hindered community growth.  This has got to stop under ASF 
"Community before code".  
We all have pressure driving our needs to get changes into master. We can do 
this and it does not have to be the old way or no way or even only one way.  
That is too controlling and it hinders Community. 

My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW & HW 
group dynamics. He asked us to think about, and ask yourself "How can I add 
value to any situation?"  When thinking from this perspective it removes Not 
Invented Here (NIH) and ego from the thinking. Some times the answer is "I can 
not add value" let the others who can do it and trust them. 

We have time to fine tune this. But we must keep it moving. 

The only thing I am suggestion 
1) Is to be able to put pr-branches, for the sake of PPMC collaboration in the 
upstream repo..
2)  Have the option to use github's well know and document WF 
3)  add branch protection to master 

This will not EXCLUDE anyone from doing it the OLD way or as you suggest below. 

> 1.User send patch against master to dev@nuttx.apache.org or
> 2.User send PR against master to https://github.com/apache/incubator-nuttx
> 3.Committer review and merge the change to master(with some
> modification if needed)
> 4.Committer make a official release and create a tag to mark the point
> every two(or three?) months
> We only need to disscuss how committer review the change and make the release.
> Since we have two month for the next release, let's focus on the
> review process in this time.
> Here are some questions I have, other may add more:
> a.How many committers need approve the patch before it can merge?
> b.How much time give the committer the chance to say no?
> Once all questions get the resonable answer, we can make a vote.
> If anyone has a new idea(e.g. submodule, dev/pr/release branch,
> backport, LTS) send your proprosal to dev list and let community
> discuss and vote.
> But before the proprosal is accepted by the community, why we stop to
> use the current workflow and make our work stuck?
> 
> Thanks
> Xiang
> 
> On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean  
> wrote:
> >
> > Hi,
> >
> > Some observations that might apply.
> >
> > I've used GitFlow on a few projects here at Apache and elsewhere, it does 
> > have some downsides, it’s overly complex and confuses beginners 
> > (particularly those unfamiliar with git),tends to create long lived 
> > branches (which are hard to merge), master and develop (or whatever you 
> > call the main two branches) tend to subtly get out of sync over time.
> >
> > You can change the GitHub default branch (you need to ask infra). A bigger 
> > issue with having master / develop and if you don’t merge frequently is 
> > that people don’t think the committers are that active, external people 
> > don't tend to look at activity on the branches.
> >
> > Note that Apache Git/GitHub has some restrictions, we don’t want history to 
> > be rewritten for legal and provenance reasons so a couple of things you may 
> > be used to doing outside of Apache may not be possible. Squashing commits 
> > in some projects tends to be frowned on for this reasons. Similarly we need 
> > to know the author of any change.
> >
> > Thanks,
> > Justin
> >
> >
> 

David

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane]

Hi Duo,

I am sorry I broke my own rule. I should have defined it. 

BD: Benevolent dictator for life (BDFL) is a title given to a small number of 
open-source software development leaders, typically project founders who retain 
the final say in disputes or arguments within the community.

On 2019/12/25 14:26:47, 张铎(Duo Zhang)  wrote: 
> Pardon me, what is a BD model? I do not get your point why requiring users
> to send a patch or open a PR against master will hindered the community
> growth? 

I was speaking of the past (pre ASF) model and the last few days, 

Specifically not acting like a team and having PR closed without consideration 
of taking the commit that was not in dispute that made the tool more useful by 
adding parse-able output. That does not foster community, it stifles it. 

 > Or you say #3 and #4? These are what we want to change.

This 3 & 4?

3.Committer review and merge the change to master(with some modification if 
needed)

(with some modification if needed) - this should only happen on a PR as one 
separate commit to be traceable. There is nothing more off putting the 250 
style changes to a users 2 line PR.

The changes I want are to support collaboration in the repo.

1) Is to be able to put pr-branches, for the sake of PPMC collaboration in
the upstream repo.

This works well  for "drive-by PRs". This is the term given to what you 
described as a PR with value, that Author does not want to take the effort to 
make changes to do it the best way for the system.
We can tag team on getting things like this in. 

If we do not do this we have to give N committers write access to N committers 
repos. That does not scale well and will encourage forks.

2)  Have the **option*** to use github's well know and document WF 
 Give the people the freedom to work in the most efficient way a person chooses 
 (GREEN and CLEAN)[1] 

3)  add branch protection to master 

Avoid any accidents - we are all human. 

4.Committer make a official release and create a tag to mark the point
every two(or three?) months

This is fine, but we will need the process documents to be consistent results. 
We have time for that.

> 
> Thanks.
> 
> David Sidrane  于2019年12月25日周三 下午9:55写道：
> 
> > Hi Xiang,
> >
> > On 2019/12/25 05:36:14, Xiang Xiao  wrote:
> > > Yes, I agree that we shouldn't make the workflow too hard to scare
> > > people for contribution.
> > > NuttX isn't a new project, it's open source for more than ten years
> > > and has a mature workflow, the whole community is already familiar
> > > with it.
> > > Let me summary the current workflow:
> > > 1.User send patch against master to
> > > https://groups.google.com/forum/#!forum/nuttx or
> > > 2.User send PR against master to
> > https://bitbucket.org/nuttx/nuttx/src/master/
> > > 3.Greg review and merge the change to master(with some modification if
> > needed)
> > > 4.Greg make a official release and create a tag to mark the point
> > > every two(or three?) months
> > > To "be apache way", the required change is only item 3&4: all
> > > committer need involve the reviewing and release process.
> > > So, I suggest that we adapter the current workflow with as minimal
> > > changes as possible:
> >
> > The above workflow was in support of a BD model who preferred to use
> > patches and refused to use github. (no disrespect intended). The value it
> > added was incredible quality (but in reality only in the areas  important
> > to the BD). At the same time hindered community growth.  This has got to
> > stop under ASF "Community before code".
> > We all have pressure driving our needs to get changes into master. We can
> > do this and it does not have to be the old way or no way or even only one
> > way.  That is too controlling and it hinders Community.
> >
> > My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW &
> > HW group dynamics. He asked us to think about, and ask yourself "How can I
> > add value to any situation?"  When thinking from this perspective it
> > removes Not Invented Here (NIH) and ego from the thinking. Some times the
> > answer is "I can not add value" let the others who can do it and trust
> > them.
> >
> > We have time to fine tune this. But we must keep it moving.
> >
> > The only thing I am suggestion
> > 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in
> > the upstream repo..
> > 2)  Have the option to use github's well know and document WF
> > 3)  add branch protection to master
> >
> > This will not EXCLUDE anyone from doing it the OLD way or as you suggest
> 

RE: [DISCUSS] Simple Workflow Proposal

[David Sidrane]

Hi Duo,

Well said and I am all for it.

Two questions:

1 Who will apply the patches?
2 Can we use and merge a PR that has been reviewed?

David


-Original Message-
From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com]
Sent: Monday, December 23, 2019 4:35 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] Simple Workflow Proposal

For our Chinese people we do not think starting working when the
requirements are not very clear is a big risk, this is what happens every
day here. You can not plan everything so just have a try, if it does not
work then just drop it and retry, no harm :)

And in my experience, if we can not agree on something, and seems the
direction of the conversation is not going to solve the problem, then we
should stop, and try to make consensus on something else, maybe on a higher
level, or a precondition of the current problem. If we can not even make a
consensus then we do not need to talk any more, honestly.

And back to the discussion here, I think we all agree that, we want the
NuttX project to be successful right? Everyone here just wants to help,
let’s be friendly to each other.

And second, what is the most emergency problem for now? I do not think it
is the workflow. We can not accept new patches, this is the biggest problem
I think. And since it is Christmas so as Greg said maybe we can delay it
for two weeks, but anyway it will still be the biggest problem after we
come back from Christmas(OK I need to say that we Chinese people do not
have Christmas holidays...).

Do we really need a new workflow for accepting patches? I do not think so,
now the only difference is that the code has been moved from bitbucket to
github, so follow the old workflow is an option I’d say. Let’s do things
step by step.

Anyway, I think we should make a consensus first, if we all agree that
accepting new patches is the most emergency problem for now, then we can
start to talk the further actions. If not, let’s first define the problem.
We really need to start from a consensus.

My two cents. Thanks.

Gregory Nutt 于2019年12月23日 周一10:02写道：

>
> > But the #1 most critical thing facing this project is adopting even
> > just the requirements for the workflow.  None of the other issues have
> > any significant importance
> >
> > So I have to be opposed to any obstacles that jeopardize or distract
> > from the #1 priority thing.
>
> One of the dangers of delaying the workflow requirements is that there
> are people actually developing workflow components now ... WITHOUT any
> requirements!!! Pull unadulterated rogue behavior. There is a great risk
> of just have some workflow foisted upon us with no ability by the PPMC
> to guide or monitor.
>
> We will be giving away our right to define the workflow it we do not
> make progress on the workflow requirements.  Yet another rogue workflow
> will be forced on us.
>
> I think we must decline any attempts to do commit unapproved workflow
> components.  We must not allow any workflow to be put into place without
> the concurrence of the PPMC.  We give our concurrence only by agreeing
> to a set of workflow requirements then enforcing those requirements.
>
> Greg
>
>
>

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane]

-Original Message-
From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
Sent: Wednesday, December 25, 2019 6:55 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)



On Wed, Dec 25, 2019 at 9:55 PM David Sidrane  wrote:

>

> Hi Xiang,

>

> On 2019/12/25 05:36:14, Xiang Xiao  wrote:

> > Yes, I agree that we shouldn't make the workflow too hard to scare

> > people for contribution.

> > NuttX isn't a new project, it's open source for more than ten years

> > and has a mature workflow, the whole community is already familiar

> > with it.

> > Let me summary the current workflow:

> > 1.User send patch against master to

> > https://groups.google.com/forum/#!forum/nuttx or

> > 2.User send PR against master to
https://bitbucket.org/nuttx/nuttx/src/master/

> > 3.Greg review and merge the change to master(with some modification if
needed)

> > 4.Greg make a official release and create a tag to mark the point

> > every two(or three?) months

> > To "be apache way", the required change is only item 3&4: all

> > committer need involve the reviewing and release process.

> > So, I suggest that we adapter the current workflow with as minimal

> > changes as possible:

>

> The above workflow was in support of a BD model who preferred to use
patches and refused to use github. (no disrespect intended). The value it
added was incredible quality (but in reality only in the areas  important
to the BD). At the same time hindered community growth.  This has got to
stop under ASF "Community before code".

> We all have pressure driving our needs to get changes into master. We can
do this and it does not have to be the old way or no way or even only one
way.  That is too controlling and it hinders Community.

>



Why is it become BD mode without PR branch? almost github project I

contributed before don't create the branch for PR, here are some

examples:

https://github.com/curl/curl/pull/4756

https://github.com/esnet/iperf/pull/935

https://github.com/OpenAMP/open-amp/pull/184



I was referring to the past. Patches were directly applied to master.



Anyone could make the comment and suggestion for PR through github UI

directly, I don't think we can't review code without PR branch here.



Even PX4 doesn't create the PR branch for each patch, for example:

https://github.com/PX4/Firmware/pull/13787

you just send it 19 hours ago which against master but without PR branch.



No. That is not the case

Note its location the BRANCH is here
https://github.com/PX4/Firmware/tree/master_SDIO_pu_fixes





> My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW
& HW group dynamics. He asked us to think about, and ask yourself "How can
I add value to any situation?"  When thinking from this perspective it
removes Not Invented Here (NIH) and ego from the thinking. Some times the
answer is "I can not add value" let the others who can do it and trust them.

>

> We have time to fine tune this. But we must keep it moving.

>

> The only thing I am suggestion

> 1) Is to be able to put pr-branches, for the sake of PPMC collaboration
in the upstream repo..



I don't reject the branch on the official repo: if some big feature

need to develop or some modification need involve multiple people, the

new branch can be created for that after the disscussion. What I don't

like is create the branch for every patch, which just make the process

more complicated and mess the official repo.

I just count PX4 repo: total 272 branches, 64 branches is old than 1

year, 150 branches is old than 1 month.



> 2)  Have the option to use github's well know and document WF

> 3)  add branch protection to master

>



Yes, before patch merge into master, it should go through the review

process documented by the workflow.

Of course, as Abdelatif note that we have to bypass the workflow in

some special case.



[DBS] Even in the extreme case You can still do the correct thing. Create a
branch, open a PR and use the ADMIN override to merge it.!!











> This will not EXCLUDE anyone from doing it the OLD way or as you suggest
below.

>

> > 1.User send patch against master to dev@nuttx.apache.org or

> > 2.User send PR against master to
https://github.com/apache/incubator-nuttx

> > 3.Committer review and merge the change to master(with some

> > modification if needed)

> > 4.Committer make a official release and create a tag to mark the point

> > every two(or three?) months

> > We only need to disscuss how committer review the change and make the
release.

> > Since we have two month for the next release, let's focus on the

> > review process in this time.

&g

RE: Workflow Development

[David Sidrane]

+1 Agree



I have not seen any WF proposals from Haitao Liu (other then on the
submodule discussion)



Haitao Liu please chime in.



Have any of you used this?



https://www.visual-paradigm.com/download/community.jsp



Awesome tool with a super efficient UI



This is an activity diagram



David





-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Wednesday, December 25, 2019 7:27 AM
To: dev@nuttx.apache.org
Subject: Workflow Development



Once we have the workflow requirements in place we need to discuss how

to manage to the workflow development.  I expect it will be a couple of

weeks before those requirements are in place, but it is not too early to

talk about the development.  There are at least two things we can

consider now:



  * Staffing.  There should be multiple people working on the workflow.

Haitao Liu is the dedicated resource for workflow development and

long term support.  Haitao must be involved, that is his job.  Other

interested parties, inside or outside the PPMC can also

participate.  Within the PPMC, I think that DavidS, Brennan, and

Anthony Merlino might have an interest in participating.

  * Branch/Repository.  I think that there should be a common branch in

github... or perhaps a new nuttx-testing repository as we have

talked about in the past.  The develop should be conducted in the

open with the full participation of the development team and with

full visibility to the community.  No backroom cooked up code.



Thoughts?



Greg

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane]

+1

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Wednesday, December 25, 2019 6:41 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)


> Why does the authors matter. There is no reason a patchset or PR needs to
> be squashed into a single commit, they just should not be broken along the
> way.

It does not matter to the project.  But it matters very much to some
contributors.  Especially young or newbie contributors who see this a
recognition by the technical community.  I have even seen people share
there commits proudly in social media.

For those of us who have been doing this for a long time, we don't need
that recognition (I have around 36,000 commits to the project), but that
is not true of others.  So I think we need to be respectful of
contributors.  I believe that we owe contributors of patches to the OS
the public recognition that they deserve.

Greg

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane]

Branch protection

https://help.github.com/en/github/administering-a-repository/about-protected-branches

About protected branches. Protected branches ensure that collaborators on
your repository cannot make irrevocable changes to branches. Enabling
protected branches also allows you to enable other optional checks and
requirements, like required status checks and required reviews.
About protected branches - GitHub Help
https://help.github.com › github › administering-a-repository ›
about-protect...

David

-Original Message-
From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com]
Sent: Wednesday, December 25, 2019 6:37 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)

David Sidrane  于2019年12月25日周三 下午9:55写道：

> Hi Xiang,
>
> On 2019/12/25 05:36:14, Xiang Xiao  wrote:
> > Yes, I agree that we shouldn't make the workflow too hard to scare
> > people for contribution.
> > NuttX isn't a new project, it's open source for more than ten years
> > and has a mature workflow, the whole community is already familiar
> > with it.
> > Let me summary the current workflow:
> > 1.User send patch against master to
> > https://groups.google.com/forum/#!forum/nuttx or
> > 2.User send PR against master to
> https://bitbucket.org/nuttx/nuttx/src/master/
> > 3.Greg review and merge the change to master(with some modification if
> needed)
> > 4.Greg make a official release and create a tag to mark the point
> > every two(or three?) months
> > To "be apache way", the required change is only item 3&4: all
> > committer need involve the reviewing and release process.
> > So, I suggest that we adapter the current workflow with as minimal
> > changes as possible:
>
> The above workflow was in support of a BD model who preferred to use
> patches and refused to use github. (no disrespect intended). The value it
> added was incredible quality (but in reality only in the areas  important
> to the BD). At the same time hindered community growth.  This has got to
> stop under ASF "Community before code".
> We all have pressure driving our needs to get changes into master. We can
> do this and it does not have to be the old way or no way or even only one
> way.  That is too controlling and it hinders Community.
>
> My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW &
> HW group dynamics. He asked us to think about, and ask yourself "How can I
> add value to any situation?"  When thinking from this perspective it
> removes Not Invented Here (NIH) and ego from the thinking. Some times the
> answer is "I can not add value" let the others who can do it and trust
> them.
>
> We have time to fine tune this. But we must keep it moving.
>
> The only thing I am suggestion
> 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in
> the upstream repo..
>
What do you mean by pr-branches? I still do not get your point why you
stick to create branches in the offical repo? Why not just use your own
fork? If you need multiple continuous commits to finish a big feature, you
can open a branch, we call it a 'feature branch'. And this usually requires
more powerful issue tracker system such as JIRA.

> 2)  Have the option to use github's well know and document WF
>
What is the well known and documented WF of github? I've never heard about
it. Please be specific.

> 3)  add branch protection to master
>
Agree if the branch protection here means disable force push.

>
> This will not EXCLUDE anyone from doing it the OLD way or as you suggest
> below.
>
> > 1.User send patch against master to dev@nuttx.apache.org or
> > 2.User send PR against master to
> https://github.com/apache/incubator-nuttx
> > 3.Committer review and merge the change to master(with some
> > modification if needed)
> > 4.Committer make a official release and create a tag to mark the point
> > every two(or three?) months
> > We only need to disscuss how committer review the change and make the
> release.
> > Since we have two month for the next release, let's focus on the
> > review process in this time.
> > Here are some questions I have, other may add more:
> > a.How many committers need approve the patch before it can merge?
> > b.How much time give the committer the chance to say no?
> > Once all questions get the resonable answer, we can make a vote.
> > If anyone has a new idea(e.g. submodule, dev/pr/release branch,
> > backport, LTS) send your proprosal to dev list and let community
> > discuss and vote.
> > But before the proprosal is accepted by the community, why we stop to
> > use the c

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane]

Even on a squashed merge there is traceability back to the PR and therefore
ALL the history will be on the mailing list and publically available on GH.

This is why a rebase work flow has to stop after review. (With some
exceptions)  but we always attribute to the Authors

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Wednesday, December 25, 2019 6:44 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)


> If they are related / dependent on each other, then I think those
> kinds of patchsets should be encapsulated in one branch.
That would work fine provided that the branch is not squashed to
master.  That loses authorship of individual contributions.

RE: 404 on site (Project status Nuttx)

[David Sidrane]

Did you see the PR for the README.md There was a typo in the MD. But the
Link looks wrong to me and I would not know where to point it at this point.

-Original Message-
From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
Sent: Friday, December 27, 2019 4:10 AM
To: dev@nuttx.apache.org
Subject: Re: 404 on site (Project status Nuttx)

I open a JIRA to get INFRA help:
https://issues.apache.org/jira/plugins/servlet/mobile#issue/INFRA-19634


On Friday, December 27, 2019, David Sidrane  wrote:

> What is in the way of fixing the 404?
>
>
>
> -Original Message-
> From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
> Sent: Friday, December 27, 2019 3:59 AM
> To: dev@nuttx.apache.org
> Subject: Re: 404 on site (Project status Nuttx)
>
> No, this git just has the website content.
> The git contain both Brennan and Hans change even Justin, you can see
> the full commit here:
> https://github.com/apache/incubator-nuttx-website/commits/master
> https://nuttx.apache.org should host the content generated from this
> git which has a link to wiki
>
> On Fri, Dec 27, 2019 at 7:50 PM spudaneco  wrote:
> >
> > How does this effect ongoing Confuence development on Brennan's old
> > site?
> > This needs to move to a new URL. What is the URL? Will additional
> > changes
> > to Brennan's site be lost?Thanks,GregSent from Samsung tablet.
> >  Original message From: Hans  Date:
> > 12/27/19  4:16 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: 404
> > on site (Project status Nuttx) Hi mentors,Xiang has already imported the
> > project website Brennan created into theofficial Apache NuttX Website
> > repository.https://github.com/apache/incubator-nuttx-websiteHow can it
> be
> > published to https://nuttx.apache.org/?Thanks,Huahang-- 刘华航 (Hans)行走,
> 思考,
> > 在路上
>

RE: squashing commits or not

[David Sidrane]

Agree! If you read the work flow I suggested you will see it is a rebase
until review WF. Noise should always be squashed.

-Original Message-
From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
Sent: Thursday, March 05, 2020 4:53 AM
To: dev@nuttx.apache.org
Subject: Re: squashing commits or not

> Because if
> the contributor take the time to split the change into serveral small
> patch, which mean it's valuable to do so.

I agree, but this isn't always the case.
It is okay to have PRs with multiple commits, as you mentioned, we can
even request to do so.
However, some of the commits are just a sequence of the same change.
That's valuable for a WIP, but IMO should've been squashed before
creating the PR.


On Thu, Mar 5, 2020 at 11:05 AM Xiang Xiao 
wrote:
>
> On Thu, Mar 5, 2020 at 5:10 PM Abdelatif Guettouche
>  wrote:
> >
> > Hi,
> >
> > We do not squash commits unless they are related (Which should have been
> > done by the OP in the firsr place).
>
> But even the patch related each other, it's better to keep the
> individual small patch instead merging into one big patch. Because if
> the contributor take the time to split the change into serveral small
> patch, which mean it's valuable to do so.
>
> it is important to keep the patch as it without modification, if the
> PR doesn't looks good, we can:
> 1.Suggest the contributor modify the change and update PR again
> 2.Or merge the PR and create a new PR fix the remaining issue.
> Of course, the second approach should be selected only for the minor
> issue(coding style, naming etc). Each individual patch should pass the
> build and no regression first.
>
> > We actually encourage putting unrelated changes in separate commits.
> >
>
> Most people send PR contain the multiple commit just because all of
> them is related each other. If not, maintainer can request the
> contributor split PR into small ones.
>
> >
> >
> > On Thu, Mar 5, 2020, 05:26 Takashi Yamamoto
> > 
> > wrote:
> >
> > > hi,
> > >
> > > it seems that in nuttx it's common to squash commits when merging pull
> > > requests.
> > >
> > > i'd like to suggest _not_ to do that because:
> > > * it makes cherry-pick/backport/revert cumbersome
> > > * larger changes are more difficult to read/understand
> > >
> > > on the other hand, i can think of only little benefit.
> > > * aesthetic reasons?
> > > * marginally save the repo size growth?
> > >
> > > how do you think?
> > >

RE: Progress on making a release

[David Sidrane]

I am unclear about the build status and what has been added and if all the
configs are in the test list.  As I read the email from Xiang Xiao - all the
builds do not build yet.  I thought in the past ALL the builds were built
before a release.


-Original Message-
From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
Sent: Thursday, February 27, 2020 6:10 AM
To: dev@nuttx.apache.org
Subject: Re: Progress on making a release

With the nightly build in place, we would want to wait for some clean
builds to consider a release.
We want to make sure that the code is stable enough.

However, we can make progress by taking care of some of Apache's
requirements.
Justin, summarized what we should do in an earlier thread. [1]
First thing is to created DISCLAIMER, LICENSE and NOTICE files.
I created a draft PR
(https://github.com/apache/incubator-nuttx/pull/392) where I added
these files.
Please check it and share your thoughts.

We also need to define our release process.
Something like:
Create a branch from master that will serve as a release candidate.
Make the necessary modifications in preparation of a release (update
release notes, documentation, etc.)
Accept only critical bug fixes to the RC, other PRs should still go to
master.

This is not a release process proposition, just a draft that I'm
writing in a hurry.
We also need to agree on versioning numbers and how bugs found after
the release should be incorporated.
Please share your thoughts.

1.
https://lists.apache.org/thread.html/r18435832d8730b14abe4715d74a8307b152d753494208843c2df499a%40%3Cdev.nuttx.apache.org%3E

On Thu, Feb 27, 2020 at 11:16 AM Xiang Xiao 
wrote:
>
> As I remember correctly, Brennan want to take the release manager role
> to finish the first release.
>
> On Thu, Feb 27, 2020 at 9:24 AM Nathan Hartman 
> wrote:
> >
> > On Wed, Feb 26, 2020 at 8:05 PM Justin Mclean 
> > wrote:
> > > Where is the project at in moving forward to make it’s next release?
> >
> > I think we should begin to plan our release procedures and release
> > schedule.
> >
> > The first thing we need is a Release Manager (RM). This need not be a
> > fixed role; we could have a different volunteer for the RM role for
> > each release, or one person could choose to be RM continuously until
> > they can't or don't wish to do it anymore.
> >
> > Do we have any volunteers?
> >
> > Cheers,
> > Nathan

RE: stm32h7 support for SDRAM via FMC

[David Sidrane]

Andrew,

My apologies! Bitbucket is a legacy mirror.

Greg can you put a Notice on the site to avoid this sort of thing.

Please submit a PR on Github

https://github.com/apache/incubator-nuttx
https://github.com/apache/incubator-nuttx-apps


David

-Original Message-
From: Заболотный Андрей [mailto:zappare...@yandex.ru]
Sent: Friday, March 06, 2020 2:37 AM
To: dev@nuttx.apache.org
Subject: stm32h7 support for SDRAM via FMC

Hello developers!

I have added support for SDRAM initialization and registration with system
heap to the FMC driver on stm32h7 family.
I would like to submit these changes to mainline NuttX.

The respective git branch is here:
https://bitbucket.org/zapparello/nuttx/branch/stm32h7-fmc

The branch currently contains three commits:

* 68e12d2 fixes out-of-tree board directory support, making it work like it
was intended (according to docs). I couldn’t test my later patches without
this one, as I use a non-standard board for development.
* 23603a0 is a small patch that prevents NuttX from crashing if developer
sets MM_REGIONS too low.
* 051e74e contains mostly changes to stm32h7/stm32_fmc.{c,h} and
stm32_allocateheap.c. Also it fixes a serious typo in stm32h7x3xx_rcc.h
which caused PLL2 and PLL3 not to work at all on stm32h7.

-- 
Andrew

RE: squashing commits or not

[David Sidrane]

> I see your point, however

I do not think the overwhelming feeling is real enough for the folks the
contributed to the document.

Now that we really see a how small (and painful submitting) the patch to PR
ratio can we not focus on the past not "best practices" and document a real
work flow?

Here is what that 10,404 word document can look like in 490 words.

https://dev.px4.io/master/en/contribute/git_examples.html#git-examples

I do not own it, I use it, it works, it informs the developer of what is
happening not hundreds of useless emails saying merged prxyz!

We need to think Team. We need to value the team's time. None of what we
have done foster communication or provide useful information. There are just
thousands of emails on a really small project. Can you imagine your inbox
with 1000 devs working on this?

We have some air time on in the Apache world. It is time to renovate!

David


-Original Message-
From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
Sent: Friday, March 06, 2020 3:30 AM
To: dev@nuttx.apache.org
Subject: Re: squashing commits or not

> Thank you. The link did not lad me and I have no idea what to look at
> there
> among the 10,404 words...

I see your point, however, the steps (and git commands) are all in one
place with the necessary explanations.  If one decides not to read
anything but the commands, they are highlighted with code blocks.

> That has never been thoroughly approved and is not the accepted workflow
> at present.

Yes, but eventually, that's the workflow we are going to call a vote on.
All committers can edit and improve it. Non committers can ask to have
the necessary permissions.


On Thu, Mar 5, 2020 at 5:55 PM David Sidrane 
wrote:
>
> Abdelatif,
>
> Thank you. The link did not lad me and I have no idea what to look at
> there
> among the 10,404 words...
>
> David
>
> -Original Message-
> From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
> Sent: Thursday, March 05, 2020 10:41 AM
> To: dev@nuttx.apache.org
> Subject: Re: squashing commits or not
>
> > How about clear to the point work steps? Do we have the interim workflow
> > listed anywhere that it can be read, without the diatribes?
>
> I just wrote something really quickly. Maybe you want to take a look [1]
> We can add to that section more information on how to squash WIP
> commits using interactive rebasing.
> I'll come back later to do more. But I need to go. Feel free to edit.
>
> 1.
> https://cwiki.apache.org/confluence/display/NUTTX/Code+Contribution+Workflow+--+Brennan+Ashton#CodeContributionWorkflow--BrennanAshton-BeforeSubmittingYourChanges
>
>
> On Thu, Mar 5, 2020 at 5:37 PM David Sidrane 
> wrote:
> >
> > I think you are over-reading this. If we do not have a clear list of
> > instructions we are not helping, we are confusing our would be
> > committers
> > (Additional Committers email). If you do not think of them as Rules but
> > more
> > of sharing your "best engineering judgment" to educate the group, you
> > know,
> > Share the knowledge help the community, help the project
> >
> > -Original Message-
> > From: Gregory Nutt [mailto:spudan...@gmail.com]
> > Sent: Thursday, March 05, 2020 9:25 AM
> > To: dev@nuttx.apache.org
> > Subject: Re: squashing commits or not
> >
> > No one gets to set any rules.  No one gets to enforce any rules.
> > Committers are free to do what they choose.  That is the Apache way:  It
> > is anarchy held together by a belief in common principles and a project
> > culture.  If you can't trust people to do that job, you are working on
> > the wrong project.
> >
> > I will no be held by any such rules.  I will always use my best
> > engineering judgement.  And I will take my scolding when I deserve it.
> >
> > What you can do, is help to educate people about the pros and cons of
> > the work in general.  You have to trust that it is everyone's intention
> > in their heart to do the best job that they can.  But you will never be
> > able to force rules to control others behavior in this environment.  No
> > one has the authority to do that.

RE: Build is broken

[David Sidrane]

Hi Takashi,

Thanks for looking at this.

Yes. Linux

To test it should I revert the revert and then apply the commit or is there
a PR I should test?

David

-Original Message-
From: Takashi Yamamoto [mailto:yamam...@midokura.com.INVALID]
Sent: Monday, February 24, 2020 10:46 PM
To: dev@nuttx.apache.org
Subject: Re: Build is broken

may i assume you are using linux?

here's a fix i tested on ubuntu.
https://github.com/apache/incubator-nuttx-apps/pull/95/commits/adb08a2634ef8df99d509a472e28a7907f73210d

On Sat, Feb 22, 2020 at 1:21 AM David Sidrane 
wrote:
>
> This is what I did:
>
> For apps and nuttx git fetch nuttx
> For apps and nuttx git checkout master
> For apps and nuttx git reset -hard nuttx/master
>
> make distclean
> ./tools/configure.sh  imxrt1060-evk:nsh
> make oldconfig
> make
>
> The results are as shown.
>
> Why are we changed the build system without testing on braches?
>
> David
>
> -Original Message-
> From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
> Sent: Friday, February 21, 2020 7:17 AM
> To: dev@nuttx.apache.org
> Subject: Re: Build is broken
>
> On Fri, Feb 21, 2020 at 10:13 AM David Sidrane 
> wrote:
>
> >  Build is broken
> >
> > Build is broken
> >
> > And the output looks very ODD - any ideas on what happened?
>
>
>
> Have you tried make distclean, reconfigure, retry build?
>
> If so, could you run a bisect since the last good known build and identify
> the offending commit?
>
> Thanks
> Nathan

RE: [DISCUSS] Wrapping up the Workflow document

[David Sidrane]

Hi Abdelatif,

Good tips! git is s powerful it is nice to lean other's tricks.

Here is my `gitlast` command (it helps me answer the question: What was I
doing?)

git for-each-ref --count=30 --sort=-committerdate
refs/heads/ --format='%(refname:short)'

How's about we add a section to the document tips and tricks and share
these?

Thanks for sharing!

David

-Original Message-
From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
Sent: Tuesday, January 28, 2020 4:50 PM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] Wrapping up the Workflow document

Hi David,

Sorry for pointing the obvious. :)

I do a lot of defensive moves myself too.
I never use fetch, pull, mege or push without paramters.
I also give my local branches different names than the remotes they are
tracking. (Usally just a prefix of the remote)
Pushing will then require specifying source and destination (git push
 src:dest)
That's more typing, but prevents some mistakes.

On Wed, Jan 29, 2020, 01:38 David Sidrane  wrote:

> Hi Abdelatif,
>
> Yes I know. It is a defensive move, on my part, that makes it safe when
> working with multiple companies who might not appreciate me sharing their
> IP.
>
> David
>
> On Tue, Jan 28, 2020, 4:30 PM Abdelatif Guettouche <
> abdelatif.guettou...@gmail.com> wrote:
>
> > Hi David,
> >
> > You can merge local branch from a different remote than the branch is
> > tracking, giving that the merge is possible of course.
> >
> > On Wed, Jan 29, 2020 at 12:15 AM David Sidrane 
> > wrote:
> > >
> > > Hi Abdelatif
> > >
> > > > Why do you prefer git reset --hard /master to git merge
> > > /master after a fetch?
> > >
> > > Because with multiple remotes I am sure what local master is set to
> with
> > a
> > > hard reset.
> > > There is no possibility of merging remote A into remote B master
> locally
> > and
> > > no merge if I had the wrong remote.
> > >
> > > David
> > >
> > > -Original Message-
> > > From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
> > > Sent: Tuesday, January 28, 2020 5:04 PM
> > > To: dev@nuttx.apache.org
> > > Subject: Re: [DISCUSS] Wrapping up the Workflow document
> > >
> > > Hi David,
> > >
> > > In the workflow, deleting the branch is only suggested _after_ the PR
> > > has been merged.
> > > What you are describing is during review, which is missing from the
> > > workflow.
> > >
> > > > I had seen a lot of PR that came into bitbucket in the past with
> > > > many
> > > > merge
> > > > commits from upstream. Rebasing avoids that.
> > > Yep, still some in Github as well. I personally cherry pick relevant
> > > commits from those PRs during review.
> > >
> > > > Should be fetch and or pull and should only result in a fast forward
> -
> > > > with
> > > > many remotes I use git reset --hard  /master after a fetch.
> > > > Then as you say, I  rebase my wip on it.
> > >
> > > With all the work in a separate branch, local fork/master shall always
> > > be behind upstream/master, which will result in a fast forward.
> > >
> > > Why do you prefer git reset --hard /master to git merge
> > > /master after a fetch?
> > >
> > >
> > >
> > >
> > > On Tue, Jan 28, 2020 at 11:16 PM David Sidrane <
> david.sidr...@nscdg.com>
> > > wrote:
> > > >
> > > > Hi Abdelatif,
> > > >
> > > > > Are you assuming that the work is always on a same feature that
> > > > > you
> > > > > submit
> > > > PRs gradually?
> > > >
> > > > It can be but does not have to be.
> > > >
> > > > > What are the cons of deleting branches?
> > > >
> > > > Lost work. A botched commit by committer and you have nothing to
> > compare
> > > > it
> > > > to. branches are FREE.
> > > >
> > > > > What merge commits?
> > > >
> > > > I had seen a lot of PR that came into bitbucket in the past with
> > > > many
> > > > merge
> > > > commits from upstream. Rebasing avoids that.
> > > >
> > > > (fetch + merge from upstream)
> > > > Should be fetch and or pull and should only result in a fast forward
> -
> > > > with
> > > > many remotes I use git reset --hard  /master after a fetch.
> 

RE: [DISCUSS] Wrapping up the Workflow document

[David Sidrane]

My general comment on the Workflow document is it is too much information
and comments.

Perhaps it can be broken into patch Workflow, git Workflow and githup
Workflow and then just list the steps.
(Think in terms of a quckstart guide for nuttx workflow)

In reading it I am still not clear on the work instructions we want to
ultimately have and are currently using.

Are the current workflow's work instructions (just the steps Alan, Greg etc
have been using) listed out in a document?

David

-Original Message-
From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
Sent: Wednesday, January 29, 2020 6:47 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] Wrapping up the Workflow document

On Wed, Jan 29, 2020 at 8:10 AM David Sidrane 
wrote:

> Good tips! git is s powerful it is nice to lean other's tricks.
>
> Here is my `gitlast` command (it helps me answer the question: What was I
> doing?)
>
> git for-each-ref --count=30 --sort=-committerdate
> refs/heads/ --format='%(refname:short)'
>
> How's about we add a section to the document tips and tricks and share
> these?


Sure! Feel free to add tips and tricks section if you'd like.

Notwithstanding tips and tricks, I'd prefer that we give canonical
recommended procedures that everyone can use successfully.

Nathan

RE: [DISCUSS] Wrapping up the Workflow document

[David Sidrane]

Funny!

I meant real streamlined work instruction. nothing ambiguous and nothing is
not needed.

Something along the lines of
https://dev.px4.io/master/en/contribute/git_examples.html

David


-Original Message-
From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
Sent: Wednesday, January 29, 2020 11:03 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] Wrapping up the Workflow document

On Wed, Jan 29, 2020 at 10:14 AM David Sidrane 
wrote:
> My general comment on the Workflow document is it is too much information
> and comments.
>
> Perhaps it can be broken into patch Workflow, git Workflow and githup
> Workflow and then just list the steps.
> (Think in terms of a quckstart guide for nuttx workflow)
>
> In reading it I am still not clear on the work instructions we want to
> ultimately have and are currently using.
>
> Are the current workflow's work instructions (just the steps Alan, Greg
> etc
> have been using) listed out in a document?

You could add a tl;dr section at the beginning, but I'd urge us to
leave the longer explanations in place.

Because my problem with terse git workflow instructions is that unless
you're a git guru, they make about as much sense as:

"To work on this project, all you have to do is fork this from here,
clone that to there, pull this from that remote, push that to this
remote, shove it over here, kick it over there, lift branch A up, yank
branch B back, push branch C sideways, release branch B and let it
snap into branch D, cut branch D off, float it downstream, raise it
three inches, drop it, pull, push, and shove a few more times for good
measure, sacrifice two chickens and a goat, and then open a pull
request. Simple!"

Cheers,
Nathan

RE: [DISCUSS] Wrapping up the Workflow document

[David Sidrane]

Hi Abdelatif,

> Are you assuming that the work is always on a same feature that you submit
PRs gradually?

It can be but does not have to be.

> What are the cons of deleting branches?

Lost work. A botched commit by committer and you have nothing to compare it
to. branches are FREE.

> What merge commits?

I had seen a lot of PR that came into bitbucket in the past with many merge
commits from upstream. Rebasing avoids that.

(fetch + merge from upstream)
Should be fetch and or pull and should only result in a fast forward - with
many remotes I use git reset --hard  /master after a fetch.
Then as you say, I  rebase my wip on it.

-Original Message-
From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
Sent: Tuesday, January 28, 2020 2:17 PM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] Wrapping up the Workflow document

Hi David,

Are you assuming that the work is always on a same feature that you submit
PRs gradually?

The git usage looks off to me. It would be better to avoid deleting branches
> and using noises merge commits.
>
What are the cons of deleting branches?
What merge commits? I don't understand this last part, do you mean that the
procedure described in the workflow will generate merge commits?
Keeping a WIP branch in synch is missing from the workflow.
Basically same as you described, that should consist of synching master
(fetch + merge from upstream) then rebasing the branch on top of master.


On Tue, Jan 28, 2020 at 8:52 PM David Sidrane 
wrote:

> The git usage looks off to me. It would be better to avoid deleting
> branches
> and using noises merge commits.
>
>
> Assume the "upstream" remote is ASF repo
> Assume "prj" remote is my remote
> Assume your code is not in master on your fork.
>
> Submission:
>
> git push prj  master_my_branch
>
> open a PR on git hub (Fill out the template - we need one)
> ...
>
> Your PR comes into master: - this can be as is:no committer  modification
> or
> with modification by the committer.
>
> Reintegration
> Put your current work on top of latest master (with your contribution +
> others)
>
> git checkout master
> git fetch upstream
> git pull upstream master (it should only be a fast forward not merge
> commits) OR git reset --hard upstream/master (no question what you get)
> git checkout master_my_branch
> (optionally if PR codes was modified by committer  - to keep your work
> safe - git -b checkout master_my_branch_PR && git checkout
> master_my_branch)
> (optionally if PR codes was modified by committer  git reset --hard  is
> the parent of master_my_branch started>)
> git rebase master
>
> In reality if the PR was taken as is (no committer  modification) the
> rebase
> on master will only add others changes under your WIP.
>
>
> Alternate for backporting  - Cherry pick your work back to your fork.
>
> This workflow ensures your branch is equal in format to the upstream and
> no
> others changes. - This may be more stable.
> git checkout master
> git fetch upstream
> git pull upstream master OR git reset --hard upstream/master (no question
> what you get)
>
> git checkout master_my_branch
> git  -b checkout master_my_branch_PR && git checkout master_my_branch
> git reset --hard 
> git log master --oneline
> ^C
> git cherry-pick  ..
>
> add -e to change the commit message i.e add [BACKPORT]
>
> David
>
> -Original Message-
> From: Miguel Ángel Herranz [mailto:mig...@midokura.com.INVALID]
> Sent: Tuesday, January 28, 2020 8:49 AM
> To: dev@nuttx.apache.org
> Subject: Re: [DISCUSS] Wrapping up the Workflow document
>
> Hi Nathan,
>
> I reviewed the document and added some inlines comments (not sure if they
> are not recommended for use though).
>
> I haven't edited/added any text though, but I will be glad to help if
> needed.
>
> Cheers,
> Miguel
>
> On Fri, Jan 24, 2020 at 4:29 PM Nathan Hartman 
> wrote:
>
> > Hi all,
> >
> > The proposed Workflow document (see [1]) has a substantial amount of
> > good information in it.
> >
> > It is not yet 100% percent complete:
> > (1) There are several "REVISIT" notes throughout.
> > (2) A few sections toward the end aren't written yet.
> >
> > However, by the 80-20 rule, I think the most important parts have been
> > written, even if some things are rough around the edges.
> >
> > I have had a LOT of overtime at my $dayjob lately, which has kept me
> > from working much on NuttX. However, I don't want to let the workflow
> > fall by the wayside. I would like to get it wrapped up so we can vote
> > on it soon.
> >
> > Please, could we have some willing volunteers proofread the document,
> > fix some of the "REVISIT" parts, and help push this document that last
> > little bit to get it into a "shippable" state?
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/display/NUTTX/Code+Contribution+Workflow+--+Brennan+Ashton
> > )
> >
> > Thanks,
> > Nathan
> >
>

RE: IMXRT1050 USDHC

[David Sidrane]

Hi Ivan,


It is correct. It fixes a bug that was added when the imxrt1020 came in.
Apparently Dave did not wire the CD pin of the IC to the socket (He used a
GPIO). But that change broke the case were the CD pin of the IC is wired to
the socket

Please See
https://github.com/apache/incubator-nuttx/commit/2e71e0632f8106d1505d313e7171904536feec45#diff-787575b8e98a29e0a9d088767a68b280

It is to use allow the use of a standard GPIO pin for card detect OR  the
use of the USDHC dedicated CD pin. (it also supports inversion of the pin or
CD detect bit)

If you wire CD to the USDHC CD pin you define PIN_USDHC1_CD (as
PIN_USDHC1_CD_n) in board.h.

See
https://github.com/apache/incubator-nuttx/blob/master/boards/arm/imxrt/imxrt1060-evk/include/board.h#L215

If you use a regular GPIO you define PIN_USDHC1_CD_GPIO (as GPIO_PORTn |
GPIO_PINn) in board.h

See
https://github.com/apache/incubator-nuttx/blob/master/boards/arm/imxrt/imxrt1020-evk/include/board.h#L271


Regards,

David

-Original Message-
From: Embedded Systems [mailto:ivanucherdj...@gmail.com]
Sent: Wednesday, January 29, 2020 11:51 PM
To: dev@nuttx.apache.org
Subject: IMXRT1050 USDHC

Hello,

I found a typo mistake in the USDHC driver related to the card detect pin.
It is a pretty simple one. Can someone tell me how toapplay a patch for it.
Or someone who know how to do it do the following changes and apply them.
Thank you in advance!

in file /arch/arm/src/imxrt/imxrt_usdhc.c

Line 379-381

  #if defined(PIN_USDHC1_CD_GPIO)
.sw_cd_gpio = PIN_USDHC1_CD_GPIO,
#endif
should be changed to
  #if defined(PIN_USDHC1_CD)
.sw_cd_gpio = PIN_USDHC1_CD,
#endif

And same file at lines 437-439

 #if defined(PIN_USDHC2_CD_GPIO)
.sw_cd_gpio = PIN_USDHC2_CD_GPIO,
#endif

should be changed to

  #if defined(PIN_USDHC2_CD)
.sw_cd_gpio = PIN_USDHC2_CD,
#endif



-- 
Kind regards,
Ivan Ucherdzhiev

Team Lead @ Barin Sports
Bulgaria
skype: ipy_44
tel: +359888927760

RE: [GitHub] [incubator-nuttx-testing] justinmclean commented on issue #2: Multibranch pipeline job example

[David Sidrane]

Yet another great argument  for github actions.

-Original Message-
From: GitBox [mailto:g...@apache.org]
Sent: Tuesday, February 04, 2020 1:26 PM
To: dev@nuttx.apache.org
Subject: [GitHub] [incubator-nuttx-testing] justinmclean commented on issue
#2: Multibranch pipeline job example

justinmclean commented on issue #2: Multibranch pipeline job example
URL:
https://github.com/apache/incubator-nuttx-testing/pull/2#issuecomment-582122695


   Hi,
   > I think the " nightly build" mind set is not the way this should be
looked at. 24Hr cycle time is not going to move this project along. The
build need to be parallelized and with results like 100 config builds in <
10 Minutes
   >
   Just be aware that the build servers are a shared resource from all
projects and we are expected to not make unreasonable demands on it. I’m not
sure if the above would be unreasonable or not.

   Thanks,
   Justin




This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[DISCUSS] adding templates for files.

[David Sidrane]

When we do get this figured out. Can we put templates in a folder in the
nuttx repo named something like:

template_c_file.txt
template_h_file.txt
template_Make_file.txt
template_ld_file.txt
template_script_file.txt

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Sunday, February 02, 2020 5:05 AM
To: dev@nuttx.apache.org
Subject: Re: [incubator-nuttx] 02/02: sched/sched/sched_getcpu.c: Add file
needed by previous commit.

FYI, you can see the coding standard document at
https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard. It
shows the form of a NuttX file and has some references to the BSD
license that should be updated.

>> Any new files developed at the ASF should have ASF headers [1] you
>> also note it down;t have a copyright line.
>>
>>
>> 1. https://www.apache.org/legal/src-headers.html#headers
>
> That page gives the text of the ASF header but not the form of the
> header in code.
>
> The NuttX coding standard would add to this in .C and C++ files:
>
> /
>
>  * Licensed to the Apache Software Foundation (ASF) under one
>  * or more contributor license agreements.  See the NOTICE file
>  * distributed with this work for additional information
>  * regarding copyright ownership.  The ASF licenses this file
>  * to you under the Apache License, Version 2.0 (the
>  * "License"); you may not use this file except in compliance
>  * with the License.  You may obtain a copy of the License at
>  *
>  *   http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in writing,
>  * software distributed under the License is distributed on an
>  * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>  * KIND, either express or implied.  See the License for the
>  * specific language governing permissions and limitations
>  * under the License.
>
> /
>
>
> Files that use # for a comment would be in a similar box composed of #
> characters.
>
> Is there any problem with this?  I will update the NuttX coding
> standard to match.

RE: [DISCUSS] adding templates for files.

[David Sidrane]

My argument for this is the coding standard document can reference the
directory and `cp` or `copy` can be used to get a properly formatted staring
point file. This is opposed to cutting and pasting from a web browser and
possibly really getting garbage in the file.

Less tools, less margin for error and a test case for nxstyle, with the
possibility to automate a replacement tool.

I would be in favor of that sort of thing.

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Sunday, February 02, 2020 5:55 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] adding templates for files.


> When we do get this figured out. Can we put templates in a folder in the
> nuttx repo named something like:
>
> template_c_file.txt
> template_h_file.txt
> template_Make_file.txt
> template_ld_file.txt
> template_script_file.txt

There are already templates at the end of the coding standard document
for .c and .h.  This is preformatted and can be lifted directly from the
document.  The coding standard is the correct place for these templates,
not some garbage directory.  I would am in favor of extending the coding
standard by an highly oppose to a garbage directory.

Re: [DISCUSS] Wrapping up the Workflow document

[David Sidrane]

Hi Abdelatif,

Yes I know. It is a defensive move, on my part, that makes it safe when
working with multiple companies who might not appreciate me sharing their
IP.

David

On Tue, Jan 28, 2020, 4:30 PM Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:

> Hi David,
>
> You can merge local branch from a different remote than the branch is
> tracking, giving that the merge is possible of course.
>
> On Wed, Jan 29, 2020 at 12:15 AM David Sidrane 
> wrote:
> >
> > Hi Abdelatif
> >
> > > Why do you prefer git reset --hard /master to git merge
> > /master after a fetch?
> >
> > Because with multiple remotes I am sure what local master is set to with
> a
> > hard reset.
> > There is no possibility of merging remote A into remote B master locally
> and
> > no merge if I had the wrong remote.
> >
> > David
> >
> > -Original Message-
> > From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
> > Sent: Tuesday, January 28, 2020 5:04 PM
> > To: dev@nuttx.apache.org
> > Subject: Re: [DISCUSS] Wrapping up the Workflow document
> >
> > Hi David,
> >
> > In the workflow, deleting the branch is only suggested _after_ the PR
> > has been merged.
> > What you are describing is during review, which is missing from the
> > workflow.
> >
> > > I had seen a lot of PR that came into bitbucket in the past with many
> > > merge
> > > commits from upstream. Rebasing avoids that.
> > Yep, still some in Github as well. I personally cherry pick relevant
> > commits from those PRs during review.
> >
> > > Should be fetch and or pull and should only result in a fast forward -
> > > with
> > > many remotes I use git reset --hard  /master after a fetch.
> > > Then as you say, I  rebase my wip on it.
> >
> > With all the work in a separate branch, local fork/master shall always
> > be behind upstream/master, which will result in a fast forward.
> >
> > Why do you prefer git reset --hard /master to git merge
> > /master after a fetch?
> >
> >
> >
> >
> > On Tue, Jan 28, 2020 at 11:16 PM David Sidrane 
> > wrote:
> > >
> > > Hi Abdelatif,
> > >
> > > > Are you assuming that the work is always on a same feature that you
> > > > submit
> > > PRs gradually?
> > >
> > > It can be but does not have to be.
> > >
> > > > What are the cons of deleting branches?
> > >
> > > Lost work. A botched commit by committer and you have nothing to
> compare
> > > it
> > > to. branches are FREE.
> > >
> > > > What merge commits?
> > >
> > > I had seen a lot of PR that came into bitbucket in the past with many
> > > merge
> > > commits from upstream. Rebasing avoids that.
> > >
> > > (fetch + merge from upstream)
> > > Should be fetch and or pull and should only result in a fast forward -
> > > with
> > > many remotes I use git reset --hard  /master after a fetch.
> > > Then as you say, I  rebase my wip on it.
> > >
> > > -Original Message-
> > > From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
> > > Sent: Tuesday, January 28, 2020 2:17 PM
> > > To: dev@nuttx.apache.org
> > > Subject: Re: [DISCUSS] Wrapping up the Workflow document
> > >
> > > Hi David,
> > >
> > > Are you assuming that the work is always on a same feature that you
> submit
> > > PRs gradually?
> > >
> > > The git usage looks off to me. It would be better to avoid deleting
> > > branches
> > > > and using noises merge commits.
> > > >
> > > What are the cons of deleting branches?
> > > What merge commits? I don't understand this last part, do you mean that
> > > the
> > > procedure described in the workflow will generate merge commits?
> > > Keeping a WIP branch in synch is missing from the workflow.
> > > Basically same as you described, that should consist of synching master
> > > (fetch + merge from upstream) then rebasing the branch on top of
> master.
> > >
> > >
> > > On Tue, Jan 28, 2020 at 8:52 PM David Sidrane  >
> > > wrote:
> > >
> > > > The git usage looks off to me. It would be better to avoid deleting
> > > > branches
> > > > and using noises merge commits.
> > > >
> > > >
> > > > Assume the "u

RE: [DISCUSS] Wrapping up the Workflow document

[David Sidrane]

Hi Abdelatif

> Why do you prefer git reset --hard /master to git merge
/master after a fetch?

Because with multiple remotes I am sure what local master is set to with a
hard reset.
There is no possibility of merging remote A into remote B master locally and
no merge if I had the wrong remote.

David

-Original Message-
From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
Sent: Tuesday, January 28, 2020 5:04 PM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] Wrapping up the Workflow document

Hi David,

In the workflow, deleting the branch is only suggested _after_ the PR
has been merged.
What you are describing is during review, which is missing from the
workflow.

> I had seen a lot of PR that came into bitbucket in the past with many
> merge
> commits from upstream. Rebasing avoids that.
Yep, still some in Github as well. I personally cherry pick relevant
commits from those PRs during review.

> Should be fetch and or pull and should only result in a fast forward -
> with
> many remotes I use git reset --hard  /master after a fetch.
> Then as you say, I  rebase my wip on it.

With all the work in a separate branch, local fork/master shall always
be behind upstream/master, which will result in a fast forward.

Why do you prefer git reset --hard /master to git merge
/master after a fetch?




On Tue, Jan 28, 2020 at 11:16 PM David Sidrane 
wrote:
>
> Hi Abdelatif,
>
> > Are you assuming that the work is always on a same feature that you
> > submit
> PRs gradually?
>
> It can be but does not have to be.
>
> > What are the cons of deleting branches?
>
> Lost work. A botched commit by committer and you have nothing to compare
> it
> to. branches are FREE.
>
> > What merge commits?
>
> I had seen a lot of PR that came into bitbucket in the past with many
> merge
> commits from upstream. Rebasing avoids that.
>
> (fetch + merge from upstream)
> Should be fetch and or pull and should only result in a fast forward -
> with
> many remotes I use git reset --hard  /master after a fetch.
> Then as you say, I  rebase my wip on it.
>
> -Original Message-
> From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
> Sent: Tuesday, January 28, 2020 2:17 PM
> To: dev@nuttx.apache.org
> Subject: Re: [DISCUSS] Wrapping up the Workflow document
>
> Hi David,
>
> Are you assuming that the work is always on a same feature that you submit
> PRs gradually?
>
> The git usage looks off to me. It would be better to avoid deleting
> branches
> > and using noises merge commits.
> >
> What are the cons of deleting branches?
> What merge commits? I don't understand this last part, do you mean that
> the
> procedure described in the workflow will generate merge commits?
> Keeping a WIP branch in synch is missing from the workflow.
> Basically same as you described, that should consist of synching master
> (fetch + merge from upstream) then rebasing the branch on top of master.
>
>
> On Tue, Jan 28, 2020 at 8:52 PM David Sidrane 
> wrote:
>
> > The git usage looks off to me. It would be better to avoid deleting
> > branches
> > and using noises merge commits.
> >
> >
> > Assume the "upstream" remote is ASF repo
> > Assume "prj" remote is my remote
> > Assume your code is not in master on your fork.
> >
> > Submission:
> >
> > git push prj  master_my_branch
> >
> > open a PR on git hub (Fill out the template - we need one)
> > ...
> >
> > Your PR comes into master: - this can be as is:no committer
> > modification
> > or
> > with modification by the committer.
> >
> > Reintegration
> > Put your current work on top of latest master (with your contribution +
> > others)
> >
> > git checkout master
> > git fetch upstream
> > git pull upstream master (it should only be a fast forward not merge
> > commits) OR git reset --hard upstream/master (no question what you get)
> > git checkout master_my_branch
> > (optionally if PR codes was modified by committer  - to keep your work
> > safe - git -b checkout master_my_branch_PR && git checkout
> > master_my_branch)
> > (optionally if PR codes was modified by committer  git reset --hard
> >  > is
> > the parent of master_my_branch started>)
> > git rebase master
> >
> > In reality if the PR was taken as is (no committer  modification) the
> > rebase
> > on master will only add others changes under your WIP.
> >
> >
> > Alternate for backporting  - Cherry pick your work back to your fork.
> >
> > This workflow ensures your branch is equal in format to the 

RE: Linker error

[David Sidrane]

Ivan,

There is a limit on what C++ can be compiled and built with Nuttx.

The key is to not include any foreign (non nuttx) headers you can see the
defconfigs setting used on PX4 here
https://github.com/PX4/Firmware/tree/master/boards/px4/fmu-v5/nuttx-config/nsh
and the things needed in Make.def here
https://github.com/PX4/Firmware/blob/master/platforms/nuttx/CMakeLists.txt#L100-L119

Of Note -nostartfiles
 -nodefaultlibs
 -nostdlib
 -nostdinc++

-fno-exceptions
-fno-rtti

Then ensure the C++ objects are not dependant on anything other that compile
time code (templates)

I hope this helps,

David

-Original Message-
From: Embedded Systems [mailto:ivanucherdj...@gmail.com]
Sent: Tuesday, February 04, 2020 1:34 AM
To: dev@nuttx.apache.org
Subject: Linker error

Hello,

I need a little bit help if possible. I am using libcxx in my project but
wil the new nuttx i start having an error during the linking

libsupc++.a(vterminate.o): In function
`__gnu_cxx::__verbose_terminate_handler()':
vterminate.cc:(.text._ZN9__gnu_cxx27__verbose_terminate_handlerEv+0xfc):
undefined reference to `_impure_ptr'


i tried the solution from here

http://nuttx.org/doku.php?id=wiki:nshhowtos:build-uclibcpp

but it does nto work with libcxx and now i am getting the following error


libsupc++.a(eh_term_handler.o):(.data._ZN10__cxxabiv119__terminate_handlerE+0x0):
undefined reference to `__gnu_cxx::__verbose_terminate_handler()'

Do someone know another solution of this problem?

Thank you in advance!

Best regards,
Ivan Ucherdzhiev

RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer problems

[David Sidrane]

DTCM and D-cache are different

You will need to add the cache clean and invalidate in the write/read
functions to support D-cache. If you open a PR on Git hub, I will have a
look at it.

For comparison an STM32F7/H7 have these functions in the correct palces.

David

-Original Message-
From: Thomas Axelsson [mailto:thomas.axels...@actia.se]
Sent: Thursday, February 20, 2020 6:12 AM
To: dev@nuttx.apache.org
Subject: RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up
buffer problems

That seems to be it! Thanks!

I was under the impression that not having DTCM enabled would mean no
caching, but after finding and turning off D-Cache in menuconfig, my board
enumerates as a USB device. Now to fix it for real.

BR
Thomas

-Original Message-
From: spudaneco 
Sent: den 20 februari 2020 13:41
To: dev@nuttx.apache.org
Subject: RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up
buffer problems

This sounds like a data cache problem.  One difference between the i.MXRT
and the LPC43 is that it has a data cache.  So you must flush the cache
before starting any DMA operation and invalidate the cache before reading
any DMAdata.GregSent from Samsung tablet.
 Original message From: Thomas Axelsson
 Date: 2/20/20  5:24 AM  (GMT-06:00) To:
dev@nuttx.apache.org Subject: IMXRT 1060 USB Device (copy of LPC43/LPC31
driver) - Set-up buffer problems

Hi,

I’m trying to get the IMXRT1060-EVK working as a USB device using the USB
OTG1 peripheral.

By comparing reference manuals, I’ve figured that the USB peripheral seems
to be identical to the one found in NXP LPC43xx (and LPC31xx). As such, I’ve
copied lpc43_usb0dev.c, replaced all the registers with the IMX RT
registers and tweaked the initialization. I have made some ugly copies
(throwing in the PLL init in the driver) that will need to be cleaned up,
once the driver is working. Also, it is currently full of small hacks,
trying to get it to work. I have included  the almost unmodified, copied
LPC43 driver, in the patch as well, for comparison.

The driver is almost working, but I’ve stumbled on a problem with reading
the Set-up buffer in the EP0 Queue Head (g_qh[0].setup) (struct that resides
in RAM).

What I’ve found is that

The host sends Get Descriptor and the device responds correctly. (Green line
in USB trace image)The host sends Set Address (not visible in Linux usbmon
trace!) but the device reads the old Get Descriptor packet from
g_qh[0].setup and responds as if Get Descriptor  was sent. (Blue line and
following red text in USB trace image)

When playing around with the code I have sometimes found .setup to be all
zeroes, when the host does  Get Descriptor, Reset, . Meaning that
the zeroes written by imxrt_usbreset() has not been overwritten by  the USB
controller.

I have also at one time managed to read .setup repeatedly, after the
ENDPTSETUPSTAT has been set, until the value changed and gotten the Set
Address. However, I’m having a hard time to reproduce it.

So it seems that the data in g_qh[0].setup is only filled correctly for the
first setup package and not updated again, or sometimes updated with a large
delay.

I have tried sprinkling some volatile, in case the imxrt_readsetup() code
would skip the memory access, without success.


Any ideas on what might be going wrong or where to dig?

I have included the current state of the driver (imxrt_usbdev.c) and a
patch+defconfig if someone wants to play on an IMXRT EVK. The patch was
generated against NuttX master branch.


Here is a snippet from the console output on the device, showing how the
device reacts to Get Descriptor followed by Set Address.
Please note that ENTRY and EP0SETUP is doubly traced since I’ve duplicated
the trace lines in the code.

Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC  
Interrupt decode5: IMXRT_TRACEINTID_DISPATCH ...
Interrupt entry 1: ENTRY
Interrupt entry 1: ENTRY0081
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC   <<---
This should have been SETADDRESS!
Interrupt decode5: IMXRT_TRACEINTID_DISPATCH


Testing the patch:
git checkout 90839b41f92aa01f1b0b24d18ee62e6efa4077d5  # or current master
apply the patch tools/configure.sh imxrt1060-evk:nsh cp downloads/defconfig
defconfig make olddefconfig make

Flash board
Connect USBOTG1 (connector J9) to host.
Press  in nsh to see the usbtrace (I did not manage to use the USB
Monitor with NSH).

(I've found that I have to toggle the boot config to  on SW7 and reset,
to be able to flash with J-Link after starting this NuttX config. It does

RE: NuttX SocketCAN implementation

[David Sidrane]

+pavel

-Original Message-
From: Peter Van Der Perk [mailto:peter.vanderp...@nxp.com]
Sent: Tuesday, February 11, 2020 6:58 AM
To: dev@nuttx.apache.org
Subject: NuttX SocketCAN implementation

Hi all,

This is a follow up to the SocketCAN integration into NuttX discussion. As
discussed before we proposed the idea to include SocketCAN support in
NuttX to provide a generic well-known interface for CAN transmission. The
initial feedback was great and Gregory Nutt looked into the possibility to
integrate SocketCAN (socket family and legal issues). The other feedback
we also got was about the realtime behavior which might suffer due to
SocketCAN. To measure the impact in realtime behavior I created a testbed
using Zephyr RTOS, which already implemented SocketCAN in their RTOS. The
results of this testbed have been posted here
https://forum.uavcan.org/t/socketcan-api-on-a-rtos/750. To summarize: from
the Zephyr SocketCAN I noticed a delay increase from interrupt to
userspace application of ~ 55us and measured jitter didn't increase and
stayed < 0.001us.

I would like gather feedback if 65us is acceptable and if the NuttX
network stack might perform better or worse than that.

Furthermore I've got some questions about some implementation details,
below the figure shows my estimated guess of the current NuttX CAN
implementation and the NuttX Ethernet implementation. If we're going to
implement SocketCAN do we want to support the old NuttX CAN implementation
and SocketCAN implementation at the same time through a single hardware
driver? Do people use the NuttX CAN implementation? Can we implement
SocketCAN through the NuttX Ethernet implementation and completely skip
the NuttX CAN implementation?


 NuttX CAN Implementation NuttX Ethernet Implementation

+---+   +---+
|  Application  |   |  Application  |
+---+   +---+
+---+   +---+
|POSIX Interface|   |POSIX Interface|
+---+   +---+
+-+   +-+   +-+   +-+
|System calls |   |VFS (fs/vfs) |   |System calls |   |BSD socket   |
| |   | |   | |   |net/sockets  |
+-+   +-+   +-+   +-+
+---+   +---+
|   NuttX CAN Driver (can.c)|   | NuttX Network driver  |
| ++ ++ |   | ++ ++ |
| |Syscall glue| |Char driver | |   | |Syscall glue| |BSD Socket  | |
| || |glue| |   | || |glue| |
| ++ ++ |   | ++ ++ |
+---+   +---+
+---+   +---+
| Hardware CAN driver   |   | Hardware MAC driver   |
+---+   +---+
+---+   +---+
|OS (sched/), memory manager|   |OS (sched/), memory manager|
|(mm/), common libraries (libs/)|   |(mm/), common libraries (libs/)|
+---+   +---+
+---+   +---+
|   Hardware|   |   Hardware|
+---+   +---+
(Note this is ASCII art use a monospace font to view correctly)


Everything is still a WIP but I would like gather feedback and come up
with an architectural concept for the SocketCAN implementation.

Best regards,
Peter van der Perk

RE: Build is broken

[David Sidrane]

This is what I did:

For apps and nuttx git fetch nuttx
For apps and nuttx git checkout master
For apps and nuttx git reset -hard nuttx/master

make distclean
./tools/configure.sh  imxrt1060-evk:nsh
make oldconfig
make

The results are as shown.

Why are we changed the build system without testing on braches?

David

-Original Message-
From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
Sent: Friday, February 21, 2020 7:17 AM
To: dev@nuttx.apache.org
Subject: Re: Build is broken

On Fri, Feb 21, 2020 at 10:13 AM David Sidrane 
wrote:

>  Build is broken
>
> Build is broken
>
> And the output looks very ODD - any ideas on what happened?



Have you tried make distclean, reconfigure, retry build?

If so, could you run a bisect since the last good known build and identify
the offending commit?

Thanks
Nathan

Build is broken

[David Sidrane]

 Build is broken

Build is broken

And the output looks very ODD - any ideas on what happened?

Leaving directory
'/home/david_s5/src/PX4/repos/mainline/NuttX/apps/platform'

arm-none-eabi-ar rcs
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/libapps.a  make[1]:
Entering directory '/home/david_s5/src/PX4/repos/mainline/NuttX/apps'
make[2]: Entering directory
'/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib'
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_init.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_parse.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_console.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_script.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_system.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_command.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_fscmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_ddcmd.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_proccmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_mmcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_timcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_envcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_syscmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_dbgcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_session.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_fsutils.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_builtin.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_mntcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_consolemain.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_test.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
make[2]: Leaving directory
'/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib' make[2]: Entering
directory '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/builtin'
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/builtin/builtin_list.home.david_s5.src.PX4.repos.mainline.NuttX.apps.builtin.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/builtin/exec_builtin.home.david_s5.src.PX4.repos.mainline.NuttX.apps.builtin.o
make[2]: Leaving directory
'/home/david_s5/src/PX4/repos/mainline/NuttX/apps/builtin' make[2]:
Entering directory
'/home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/readline'
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/readline/readline.home.david_s5.src.PX4.repos.mainline.NuttX.apps.system.readline.o
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/readline/readline_common.home.david_s5.src.PX4.repos.mainline.NuttX.apps.system.readline.o
make[2]: Leaving directory
'/home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/readline' make[2]:
Entering directory
'/home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/nsh'
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/nsh/nsh_main.home.david_s5.src.PX4.repos.mainline.NuttX.apps.system.nsh.o
make[2]: Leaving directory
'/home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/nsh' make[2]:
Entering directory
'/home/david_s5/src/PX4/repos/mainline/NuttX/apps/platform'
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/platform/dummy.home.david_s5.src.PX4.repos.mainline.NuttX.apps.platform.o
make[2]: Leaving directory
'/home/david_s5/src/PX4/repos/mainline/NuttX/apps/platform' make[1]:
Leaving directory '/home/david_s5/src/PX4/repos/mainline/NuttX/apps'

arm-none-eabi-ar: make[1]:: No such file or directory

Makefile:118: recipe for target
'/home/david_s5/src/PX4/repos/mainline/NuttX/apps/libapps.a' failed

make[1]: *** [/home/david_s5/src/PX4/repos/mainline/NuttX/apps/libapps.a]
Error 1

make[1]: Leaving directory
'/home/david_s5/src/PX4/repos/mainline/NuttX/apps'

tools/LibTargets.mk:198: recipe for target '../apps/libapps.a' failed

RE: Build is broken

[David Sidrane]

Hi Takashi

Spot on!

Reverting 5cb020c70f14b2ff766c96da87c3c4bfd32c

Fixes the build.

Please test these changes on all build platforms before merging.

David

-Original Message-
From: Takashi Yamamoto [mailto:yamam...@midokura.com.INVALID]
Sent: Friday, February 21, 2020 7:25 AM
To: dev@nuttx.apache.org
Subject: Re: Build is broken

it's likely because of
https://github.com/apache/incubator-nuttx-apps/commit/5cb020c70f14b2ff766c96da87c3c4bfd32c
i suspect APPOBJS variable contains some garbage output from make
itself. like "make[2]: Leaving directory"

On Sat, Feb 22, 2020 at 12:13 AM David Sidrane 
wrote:
>
>  Build is broken
>
> Build is broken
>
> And the output looks very ODD - any ideas on what happened?
>
> Leaving directory
> '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/platform'
>
> arm-none-eabi-ar rcs
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/libapps.a  make[1]:
> Entering directory '/home/david_s5/src/PX4/repos/mainline/NuttX/apps'
> make[2]: Entering directory
> '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib'
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_init.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_parse.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_console.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_script.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_system.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_command.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_fscmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_ddcmd.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_proccmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_mmcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_timcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_envcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_syscmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_dbgcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_session.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_fsutils.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_builtin.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_mntcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_consolemain.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_test.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> make[2]: Leaving directory
> '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib' make[2]:
> Entering
> directory '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/builtin'
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/builtin/builtin_list.home.david_s5.src.PX4.repos.mainline.NuttX.apps.builtin.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/builtin/exec_builtin.home.david_s5.src.PX4.repos.mainline.NuttX.apps.builtin.o
> make[2]: Leaving directory
> '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/builtin' make[2]:
> Entering directory
> '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/readline'
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/readline/readline.home.david_s5.src.PX4.repos.mainline.NuttX.apps.system.readline.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/readline/readline_common.home.david_s5.src.PX4.repos.mainline.NuttX.apps.system.readline.o
> make[2]: Leaving directory
> '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/readline'
> make[2]:
> Entering directory
> '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/nsh'
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/nsh/nsh_main.home.david_s5.src.PX4.repos.main

RE: Build is broken

[David Sidrane]

Hmm - what value is a 24 hr cycle time? The build was broken and we did not
know it.



How about getting actions wired against a set of container that can build
nuttx target without pulling tools?



Then run 9-10 separate build on EVERY PR

3 arm linux

3 non arm linux

1 windows arm

1 windows mac

1 sim linux



Then get the badge on the PRs



It will look like this:



And add the [![Build Status] to the README.md









-Original Message-
From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
Sent: Friday, February 21, 2020 9:55 PM
To: dev@nuttx.apache.org
Subject: Re: Build is broken



On Sat, Feb 22, 2020 at 12:58 AM Nathan Hartman

 wrote:

>

> On Fri, Feb 21, 2020 at 11:21 AM David Sidrane 

> wrote:

>

> > This is what I did:

> >

> > For apps and nuttx git fetch nuttx

> > For apps and nuttx git checkout master

> > For apps and nuttx git reset -hard nuttx/master

> >

> > make distclean

> > ./tools/configure.sh  imxrt1060-evk:nsh

> > make oldconfig

> > make

> >

> > The results are as shown.

> >

> > Why are we changed the build system without testing on braches?

>

>

> We should be testing build system changes a bit more carefully. In
addition

> I think the CI system is supposed to do this as well (nightly?) Has that

> gone "live" yet?

>



Haitao has scheduled apache Jenkins nightly build several weeks ago,

here is the recent output:

https://builds.apache.org/job/NuttX-Nightly-Build/38/display/redirect

In these weeks, Haitao and I already made many change to improve the

build system and integrate our build system with apache/github

infrastructure.

The parellel build is the last issue which block we enable the nightly

and preheck build, so please either fix yamt's patch or take our

method ASAP:

https://github.com/apache/incubator-nuttx-apps/pull/87

https://github.com/apache/incubator-nuttx-apps/pull/83



Here has more backgournd info:

https://github.com/apache/incubator-nuttx/pull/102



> Thanks for catching this quickly.

>

> Nathan

RE: [DISCUSS]Bug Tracking

[David Sidrane]

> Where does the GitHub Projects reside?

Per repo and per Organization

> To me the core OS one was the right place, but that
seems to be off the table, I fail to see how tracking a release including
the apps (especially if the tickets are open against the apps project) is
tainting the quality of the OS.

I think there is a perception that "How good" the OS is should not be judged
by "How good" the apps are.
So 10 Issues all on Apps and 1 issue against the OS but all logged in the OS
repo is what is meeting resistance.
Call it "quality inferences"

Myself, I do not share that point of view. In my view: an App or OS bug is
still a problem if we are using both OS and APPs.

I think about where issues belong more as a matter of compartmentalization
and not quality inferences:

Having apps that has issues focuses the conversation on APPS.
Having OS that has issues focuses the conversation on the OS.

If a user does not use apps then why tell them of all the issues in the OS
repo?

If there is linkage use Markup to link them [Effects APP](url) and [Effects
OS](url) and that is all that is needed to cross reference them.

David

-Original Message-
From: Brennan Ashton [mailto:bash...@brennanashton.com]
Sent: Wednesday, January 15, 2020 10:24 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS]Bug Tracking

On Wed, Jan 15, 2020, 10:09 AM David Sidrane 
wrote:

> +1 for Github issues per repo.
>
> Repos can be cross referenced in markup.
> Assignees can be assigned
> labels can be assigned.
> Projects (roll up across repos) can be assigned.
> Milestones can be assigned.
> UI is simple and effective Query by any of the above attributes.
> The interfaces is present when on Github - there is no need secondary
> login/account
> The content can be rich.
>

Where does the GitHub Projects reside? What I was pushing for was a single
place not per repo. To me the core OS one was the right place, but that
seems to be off the table, I fail to see how tracking a release including
the apps (especially if the tickets are open against the apps project) is
tainting the quality of the OS.

--Brennan

>

RE: [DISCUSS]Bug Tracking

[David Sidrane]

+1 for Github issues per repo.

Repos can be cross referenced in markup.
Assignees can be assigned
labels can be assigned.
Projects (roll up across repos) can be assigned.
Milestones can be assigned.
UI is simple and effective Query by any of the above attributes.
The interfaces is present when on Github - there is no need secondary
login/account
The content can be rich.

We can add issue from email if someone does not have access to github.


-1 for any other external issue tracking system.

They add no value above what is built into ghithub.
They complicate coordination (PR closes issue).
In a general sense: The choice if an external system violates 3NF.


I do not agree that issues OR Code changes will continue to come in by
email.

I believe the root cause of that historical dataflow is an artifact bad
process and tooling. When the correct process are in place, as is the
correct tooling, there can be support for historical manual ways, but it
will be less used because it is not as efficient, it is not fool proof or
effective.

David


-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Tuesday, January 14, 2020 5:29 PM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS]Bug Tracking

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: [DISCUSS] Remove Windows Native support?

[David Sidrane]

+1 FIX THE WINDOWS NATIVE SUPPORT && add a native test environment

-Original Message-
From: Alin Jerpelea [mailto:jerpe...@gmail.com]
Sent: Thursday, January 16, 2020 4:06 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] Remove Windows Native support?

I am for option 3 FIX THE WINDOWS NATIVE SUPPORT
An initial effort is worth updating the support and I we can add a native
test environment to be sure that it builds daily

Alin

On Thu, Jan 16, 2020 at 12:22 PM Nathan Hartman 
wrote:

> On Wed, Jan 15, 2020 at 8:25 PM Gregory Nutt  wrote:
>
> > I would like to open a discussion for 72 hours then call a vote. The
> > topic is "Should we remove Windows native build support?"
> >
> > What is the Windows native build?  Is is a build option that supports
> > building NuttX in a pure Windows environment such as from a Windows IDE
> > or from CMD/PowerShell command line.  It differs primarily in that it
> > cannot use Bash features or Bash .sh scripts, but instead must use
> > commands from CMD.exe and .bat scripts.
> >
> > Please see the discussion here that is leading to the vote:
> > https://github.com/apache/incubator-nuttx/pull/102
> >
> > I think this needs a vote because (1) it is clear contradiction to the
> > Inviolables and (2) it could have significant, negative impact to NuttX
> > users down the road (although I don't think any current NuttX user would
> > be impacted).  The cost vs the benefit is not entirely clear to me.
> >
> > PRO Removal:
> >
> >   * The Windows native native support is seldom used and lags the POSIX
> > environment builds.  As a consequence, it is usually broken.
> > Historically, people who need the native have to contribute fixes to
> > get the build back into working shape.
> >   * Documentation current claims that NuttX supports the Windows native
> > build but that build is never verified and is probably not working
> > at any given time.
> >   * The Windows native build adds a lot complexity to the build system.
> >
> > ANTI Removal
> >
> >   * Although, the Windows native build is probably broken at any given
> > time, it has historically not been a huge effort to get it back into
> > shape.  That might be different now since there has been a
> > significant re-write to the apps/ build, in particular.
> >   * There are users whose customer base absolutely requires the Windows
> > native build.  Good user oriented support would require that we
> > support the Windows the native build.
> >   * Removing the Windows native build for reasons of convenience and
> > expediency and without regard to the needs of the NuttX user is very
> > much in contradiction to the OS principles (i.e., the Inviolables).
> >
> > Please offer your opinion.  You should not take the position of someone
> > who only cares about your personal use of Linux.  Please think in terms
> > of the bigger picture of what is good for the project and for the users
> > of the project in the long run.
> >
> > I will end the discussion and start the vote in the evening of January
> 18.
>
>
> I would prefer that we keep the ability to build on native Windows. That
> is
> still the most prolific OS and is used heavily in the embedded development
> world. Every microcontroller vendor I've worked with seems to support
> Windows based tools first and other platforms as an option. Sometimes
> other
> platforms are not supported at all. We already have the build system in
> place. If we could have a buildbot running nightly build tests then we'd
> be
> assured of its continued quality. Also we would keep in the spirit of the
> INVIOLABLES, which, as you've said before, we shouldn't violate for our
> own
> convenience or expediency.
>
> Nathan
>

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: [VOTE] Remove Windows Native support?

[David Sidrane]

-1

Keep it. It enables adoption.

David

-Original Message-
From: cheshmedzh...@gmail.com [mailto:cheshmedzh...@gmail.com]
Sent: Monday, January 20, 2020 8:25 AM
To: dev@nuttx.apache.org
Subject: RE: [VOTE] Remove Windows Native support?

-1
Keep It. It is useful, less or more...

Best regards

-Original Message-
From: Gregory Nutt 
Sent: Monday, January 20, 2020 4:20 PM
To: dev@nuttx.apache.org
Subject: [VOTE] Remove Windows Native support?

The [DISCUSS] phase has complete and comments have been received.  It is
time to vote for or against removing Windows native support from the NuttX
RTOS.

Anyone in the community may vote on this question to express their opinion.
However, only votes form PPC members will used to determine the outcome.   A
minimum of 3 PPMC +1 votes and more +1 PPMC votes than
-1 PPMC are required to pass this vote.

You may vote one of the following:

[ ] +1 Remove all support for the Windows native build from the RTOS
[ ]  0 No strong opinion
[ ] -1 Retain support for the Windows native build in the RTOS

Voting will close in 72 hours.

Re: Issue Reporting

[David Sidrane]

Thank You!

On Thu, Jan 9, 2020, 10:27 PM Brennan Ashton 
wrote:

> Ok we now have issues and projects on apache-nuttx.
> No projects have been configured, but I suspect a lot of the project
> management features that people were asking about can be handled via this,
> see the docs:
>
> https://help.github.com/en/github/managing-your-work-on-github/about-project-boards
>
> Also we should probably add issue templates for Bugs, Features, etc...
> This is a great place to point people to helpful things like the "how to
> debug hard-faults" article.
> If you are not familiar with this GitHub feature, Zephyr makes good use of
> it:
> https://github.com/zephyrproject-rtos/zephyr/issues/new/choose
> They come from templates placed in this directory:
>
> https://github.com/zephyrproject-rtos/zephyr/tree/master/.github/ISSUE_TEMPLATE
>
> --Brennan
>
> On Thu, Jan 9, 2020 at 7:03 PM Brennan Ashton 
> wrote:
>
>> I was going to only apply it to the os repo so we have one place to
>> triage/manage and people might not know where to file an issue or I might
>> span both. We can use labels to further filter, this is how I usually see
>> it done for projects with multiple repos.
>>
>> We can always enable the apps one later if it makes more sense.
>>
>> --brennan
>>
>> On Thu, Jan 9, 2020, 6:56 PM Xiang Xiao 
>> wrote:
>>
>>> Ok, I have closed it.
>>>
>>> On Fri, Jan 10, 2020 at 10:51 AM Brennan Ashton <
>>> bash...@brennanashton.com> wrote:
>>>
>>>> As I said we control this. I'll open the correct PR, let's not bother
>>>> infra when it is on us.
>>>>
>>>> --Brennan
>>>>
>>>> On Thu, Jan 9, 2020, 6:43 PM Xiang Xiao 
>>>> wrote:
>>>>
>>>>> I justed open a JIRA for this:
>>>>> https://issues.apache.org/jira/browse/INFRA-19692
>>>>>
>>>>> Thanks
>>>>> Xiang
>>>>>
>>>>> On Fri, Jan 10, 2020 at 4:55 AM Gregory Nutt 
>>>>> wrote:
>>>>>
>>>>>> My preference would be to let users submit issues on github, but then
>>>>>> track them with Jira.  Is it possible to link Jira issues to github 
>>>>>> issues?
>>>>>>
>>>>>> Otherwise, the rest that you say makes good sense.
>>>>>>
>>>>>> We do need to consolidate issues in one place somehow.  Currently,
>>>>>> there are issues in apps and nuttx Bitbucket, we will open up for issues 
>>>>>> on
>>>>>> apps and nuttx github.  And there is the TODO list in the nuttx 
>>>>>> repository
>>>>>> (and I have my own TODO list which should be passed upward.
>>>>>>
>>>>>> That seems like a recipe for things falling through the crack (as
>>>>>> they already have).
>>>>>> On 1/9/2020 2:21 PM, Brennan Ashton wrote:
>>>>>>
>>>>>> It seems like most people are pushing towards the simplicity of
>>>>>> GitHub. My main objection was that we put such a focus on letting people
>>>>>> submit code without using GitHub that it seemed odd to then force GitHub
>>>>>> for issues. JIRA can really do a lot but I see it as tool that gives you 
>>>>>> a
>>>>>> million features and leaves you to wire it up (I have used it for work 
>>>>>> for
>>>>>> many years) Unless there is someone that wants to do the wiring work it's
>>>>>> likely not going to be better than what we get with GitHub.
>>>>>>
>>>>>> As for the project management component, we can enable the GitHub
>>>>>> features for that. It's simple but plenty powerful for what we likely 
>>>>>> need
>>>>>> to so. Even creating filtered views with tags is likely all we need for
>>>>>> some time.
>>>>>>
>>>>>> I would propose we open up GitHub issues only on the apache-nuttx
>>>>>> project and start there and let it naturally grow.
>>>>>>
>>>>>> If we need to move to JIRA for some reason as the project grows, I'll
>>>>>> volunteer to move the data.
>>>>>>
>>>>>> This can all be turned on with the .asf.yml file and I can submit the
>>>>>> pr for that if we want.
>>>>>>
>

Re: What happened to (void) for ignored return values?

[David Sidrane]

Yes. labeled "interim work flow", and should it be voted on prior to use,
(but at this point It is rather moot)

On Fri, Jan 3, 2020 at 9:26 AM Alan Carvalho de Assis 
wrote:

> Hi David,
>
> Good question!
>
> I didn't create it as an ASF wiki page because it is not official and
> I think we need to focus on finishing the new workflow. But because we
> need to avoid the chaos I decided to write it on some other place and
> eventually it could be useful for other people until we get the new
> workflow.
>
> I don't know. Do you think we should move it to ASK wiki?
>
> BR,
>
> Alan
>
> On 1/3/20, David Sidrane  wrote:
> > Given all the input from ASF mentors : Should this live on the ASF Nuttx
> > servers,  possibly labeled "interim work flow", and should it be voted on
> > prior to use?
> >
> > On Fri, Jan 3, 2020 at 7:12 AM Alan Carvalho de Assis  >
> > wrote:
> >
> >> Hi Nathan,
> >>
> >> On Friday, January 3, 2020, Nathan Hartman 
> >> wrote:
> >> > On Thu, Jan 2, 2020 at 10:54 PM Nathan Hartman
> >> >  >> >
> >> > wrote:
> >> >
> >> >> On Thu, Jan 2, 2020 at 10:31 PM Gregory Nutt 
> >> wrote:
> >> >>
> >> >>>
> >> >>> > Ok. I'm okay with that.
> >> >>>
> >> >>> Perhaps you could merge this for me:
> >> >>>
> >> >>> https://github.com/apache/incubator-nuttx/pull/31
> >> >>
> >> >>
> >> > Looks like Alan beat me to it.
> >> >
> >> >
> >>
> >> There were 3 PRs already today morning, so I had to do it.
> >>
> >> Few days ago Greg taught me his process, I created a post that could be
> >> uselful until we come up with the new workflow:
> >>
> >> https://acassis.wordpress.com/2020/01/02/the-old-way-nuttx-workflow/
> >>
> >> BR,
> >>
> >> Alan
> >>
> >
> >
> > --
> >
> > *David Sidrane*
> >
> >
> >
> > *343 Vista Royale Dr.*
> >
> > *Palm Desert, CA 92211*
> >
> >
> > *david.sidr...@nscdg.com *
> >
> > *Skype:  david_s5*
> >
> >
> >
> > *Voip:904.638.9004 Phone: 808.780.9004 Fax:  206.339.8691*
> >
>


-- 

*David Sidrane*



*343 Vista Royale Dr.*

*Palm Desert, CA 92211*


*david.sidr...@nscdg.com *

*Skype:  david_s5*



*Voip:904.638.9004 Phone: 808.780.9004 Fax:  206.339.8691*

FW: [PX4/Firmware] To test [PX4/NuttX] [BACKPORT] STM32F7 and STM32H7 SDMMC internal pull up usage fixed (#78) (#13787)

[David Sidrane]

FYI



*From:* modaltb [mailto:notificati...@github.com]
*Sent:* Monday, December 30, 2019 4:13 PM
*To:* PX4/Firmware
*Cc:* David Sidrane; Author
*Subject:* Re: [PX4/Firmware] To test [PX4/NuttX] [BACKPORT] STM32F7 and
STM32H7 SDMMC internal pull up usage fixed (#78) (#13787)



Tested over 300 arm/disarms to create logs, had NO errors on our hardware
with this mod. Before this mod we'd get failures frequently, so looking
good on my end.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/PX4/Firmware/pull/13787?email_source=notifications_token=AAO3BXOI6KP4QZW5SKFFE53Q3KE7DA5CNFSM4J7AMFXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH3PNPI#issuecomment-569833149>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAO3BXPAISYF7VWY4ML46LTQ3KE7DANCNFSM4J7AMFXA>
.

[DISCUSS] RE: Working Effectively (was Point of Order)

[David Sidrane]

2 options are up for discussion

1.Ensure the changed/new code (per line in file) comply with the coding
standard
2.Ensure the whole modified file comply with the coding standard

See below for positions

-Original Message-
From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
Sent: Monday, December 30, 2019 6:01 PM
To: dev@nuttx.apache.org
Subject: Re: Working Effectively (was Point of Order)

On Tue, Dec 31, 2019 at 7:09 AM David Sidrane 
wrote:
>
> Hold on!
> Having a coding standard with 4000+ files in the repo that do not pass the
> test…
> …reminds me of this great line…
> "This is the problem with issuing purity tests you cannot yourself pass"
> Clear, Consistent, Standardized Coding Style
> 
>   o Strict conformance to the NuttX coding style.  No "revolutionary"
> changes to the coding standard (but perhaps some "evolutionary"
> changes).
>
>   o Personal or organizational preference is not a justification for a
> coding style change.
>
>   o Nothing can come into NuttX that does not follow the coding standard.
>
>   o Expediency is not a justification for violating the coding standard.
>
>   The NuttX coding standard can be found here:
>   http://www.nuttx.org/doku.php?id=documentation:codingstandard
> How can you be suggesting facilitating this to continue this?
> It is a violation of the INVIOLABLES.txt!.
>
> "
> For example, if people send a patch or pull request, nxstyle will
> complain if the original file already has the style issue even the
> contrbutor don't modify that portion.
> "
> Rule is: If you change a file you fix the coding standard in it.
> The real issues is the code that is not compliant is used by other and
> spreads like a weed!
> Kill the weeds!
>

We have two options:
1.Ensure the changed/new code comply with the coding standard
2.Ensure the whole modified file comply with the coding standard
If the community like the 2nd option, I am fine.

> David
>
> -Original Message-
> From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
> Sent: Monday, December 30, 2019 7:45 AM
> To: dev@nuttx.apache.org
> Subject: Re: Working Effectively (was Point of Order)
>
>
>
> On Mon, Dec 30, 2019 at 11:05 PM David Sidrane 
> wrote:
>
> >
>
> > >Haitao is preparing a script for style check, the feature include:
>
> > >1.Auto build nxstyle
>
> >
>
> > 2.Improve nxstyle to check the partial file for supporting patch like
> > file
>
> >
>
> > Are you saying only check the files changed?
>
> >
>
>
>
> Yes, I mean that nxstyle just check the changing line.
>
>
>
> > If not would you please explain and give and an example of use case of
> this?
>
> >
>
>
>
> For example, if people send a patch or pull request, nxstyle will
>
> complain if the original file already has the style issue even the
>
> contrbutor don't modify that portion.
>
>
>
> > >3.Input can be the source files, patch file or commit id
>
> >
>
> > -Original Message-
>
> > From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
>
> > Sent: Monday, December 30, 2019 6:20 AM
>
> > To: priv...@nuttx.apache.org
>
> > Subject: Re: Working Effectively (was Point of Order)
>
> >
>
> > On Sun, Dec 15, 2019 at 3:26 AM Gregory Nutt 
> > wrote:
>
> > >
>
> > >
>
> > >   Perhaps we should get Jira up to track PPMC issues?  Perhaps a
> group
>
> > > issues list on Jira could coordinate what needs to get done?
>
> > >
>
> > > This are the things that are in progress now and need to be monitored:
>
> > >
>
> > > Discussion and vote for new committers
>
> > > Transfer of nuttx.org content to Confluence.  Justin mentioned that
> > > the
>
> > > ticket is in place to do this now.
>
> >
>
> > It's better to:
>
> > 1.redirect nuttx.org to nuttx.incubator.apache.org
>
> > 2.nuttx.incubator.apache.org host the content from
>
> > https://github.com/apache/incubator-nuttx-website
>
> > 3.user can navagte to wiki from the home page.
>
> > Brennan, do you know how to update nuttx.incubator.apache.org? INFRA
>
> > send me a link:
>
> >
> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories
>
> >
>
> > > Transfer the NuttX repositories.  The SGA has been signed and
> > > submitted.
>
> > > There is no INFRA ticket to do this yet.
>
> > > Workflow planning and implementation.  Not much progress here.  We
> > > need
> to
>
> > > have a requirements document that we all concur with.  Implementation
>
> > > depends having those requirements and on having the GIT repositories
> > > in
>
> > > place.
>
> > >
>
> >
>
> > Haitao is preparing a script for style check, the feature include:
>
> > 1.Auto build nxstyle
>
> > 2.Improve nxstyle to check the partial file for supporting patch like
> > file
>
> > 3.Input can be the source files, patch file or commit id
>
> >
>
> > > Am I missing anything?
>
> > >
>
> > > We should set some objectives.  Do you think we could get 3 of the
> above 4
>
> > > completed next week?
>
> > >
>
> > > Greg
>
> > >
>
> > >