Pi/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 ho
: 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
he 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]
>
ane 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.
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.
Depends on the popularity of
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
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
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.
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
I think we can learn the good practice from PX4, but shouldn't take
all without any justification.
PX4 has the mature workflow, maybe we can extract the core OS part as
our base to boost the initial setup.
The important thing now is to define the high level workflow and vote
in the community.
Then
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
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.
> > >
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.
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
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
Hi,
> 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
] 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
al 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... (Wit
Greg, please read the first post again.
Hi,
> ] 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
Changes that affect the build system should require three +1 binding
votes and no vetoes from PMC members
Other projects that I know of that have tried an approach like, seem to have a
lot of difficultly get those 3 +1 votes. This slows down development or worse
forms groups of people that
Hi,
>> Changes that affect the build system should require three +1 binding
>> votes and no vetoes from PMC members
Other projects that I know of that have tried an approach like, seem to have a
lot of difficultly get those 3 +1 votes. This slows down development or worse
forms groups of
On Thu, Dec 19, 2019 at 8:30 AM Gregory Nutt wrote:
> On Thu, Dec 19, 2019 at 3:32 AM Sebastien Lorquet
> wrote:
>> But the endless list of complex git commands with additional options is
>> probably
>> a blocker for many other people too.
>>
>> I dont even want to read it all.
>
> You and me
Looks really complex to me, if any contributor has to master all of this
perfectly to contribute officially.
the submodule sync with these specific options is already too much.
do you really realize all that has to be memorized just for a hat repo?
to put it another way: if you assure me
Reading through the thread, it seems to me that the "git submodules"
suggestion from David sounds like a "risk".
I would like to mention that it is not: it can be seamlessly added, used
for a while, and removed later without any consequences. Creating this "hat
repo" would have exactly the same
Niskanen
From: Sebastien Lorquet
Sent: Thursday, December 19, 2019 10:32 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS - NuttX Workflow]
Looks really complex to me, if any contributor has to master all of this
perfectly to contribute officially.
the submodule
(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.apach
Hi,
> However, in order to workaround one jenkins job cannot receive two github
> repos webhook trigger( or I haven't found it yet : ( ), assign two jenkins
> job instead.
There are a number of way around this e.g. off top of my head multiple step
pipeline, jenkins run a shell script to check
David, sorry that my expression was not clearly. What I meant is keep only
two repositories apps/ and nuttx/ instead of sub-modules.
However, in order to workaround one jenkins job cannot receive two github
repos webhook trigger( or I haven't found it yet : ( ), assign two jenkins
job instead.
On Wed, Dec 18, 2019, 5:06 PM Justin Mclean
wrote:
> Nhi,
>
> > This conversation got me thinking: would we want a repository to write a
> > community-written-and-maintained NuttX book?
> >
> > I think this would have a couple of advantages:
> >
> > (1) Keeps the "official" documentation within
Nhi,
> This conversation got me thinking: would we want a repository to write a
> community-written-and-maintained NuttX book?
>
> I think this would have a couple of advantages:
>
> (1) Keeps the "official" documentation within the umbrella of the project.
>
> (2) Provides an additional way
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 ;)
But only when we discussing details of implementation... AFTER we have
established functional requirements. Git discussions are
We’ve digressed a bit on this thread. Let’s see if we can reboot DavidS’
Workflow thread and keep the thread on topic.
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
On Wed, Dec 18, 2019 at 6:45 PM Gregory Nutt wrote:
>
> >>> Ben ve Veen has started a Getting Started Book and, as I recall, even
> >> has a publisher in mind. He posted his status in the original thread
> the I
> >> renamed. Perhaps you could discuss ways to collaborate?
> >>
> >> I saw that.
Ben ve Veen has started a Getting Started Book and, as I recall, even
has a publisher in mind. He posted his status in the original thread the I
renamed. Perhaps you could discuss ways to collaborate?
I saw that. I have published a book (on Android), writing it was a large
amount of work
On Wed, Dec 18, 2019 at 5:20 PM Justin Mclean
wrote:
> > Ben ve Veen has started a Getting Started Book and, as I recall, even
> has a publisher in mind. He posted his status in the original thread the I
> renamed. Perhaps you could discuss ways to collaborate?
>
> I saw that. I have published
Those of you that are used to the fast-response, shoot-from-the-hip
style of the old BSD NuttX will in for a rude awakening. There will be
some bureaucracy, some overhead, and lots of processes. The processes
are, I believe, good for NuttX. It is now too large and too critical to
depend on
A little. :-) I've worked on a few commercial projects in recent
years and way back I did SCADA and real time systems and been
involved as a hobbyist for 15 or so years. I’m spoken at the Open
Hardware Summit and given a number of IoT and MyNewt talks at various
conferences, and run
Hi,
To answer a couple of your questions.
> over 2 weeks nuttx.apache.org has content?
Would be good to start what to do about this in another thread. Having a
website even if minimal to start with is sort of important.
> Jira is up?
From what I can see it not decided if JIRA is needed or
A little. :-) I've worked on a few commercial projects in recent years and way
back I did SCADA and real time systems and been involved as a hobbyist for 15
or so years. I’m spoken at the Open Hardware Summit and given a number of IoT
and MyNewt talks at various conferences, and run basic
With Nathan's workflow on another thread, DavidS's workflow early in
this thread, Nathan's workflow on this thread, Nathan's workflow with my
appended workflow, and Justin's comments ... Do we have enough to define
an initial workflow? I think so. Some of it is a little inconsistent
(but not
Hi,
> That is great that you could commit. I notice that you are the Chair of the
> Mynewt project, so you must have some familiarity.
A little. :-) I've worked on a few commercial projects in recent years and way
back I did SCADA and real time systems and been involved as a hobbyist for 15
We need to get this discussion onto a separate thread. I just created a
getting started thread, but I think we just crossed paths
On 12/18/2019 4:00 PM, Disruptive Solutions wrote:
Maybe one can make a roadmap and milestones when we can expect things getting
back to “normal”. What is who
Maybe one can make a roadmap and milestones when we can expect things getting
back to “normal”. What is who doing and what has to be done?
Maybe its better to write a getting started guide how to contribute? Making
patches, code conventions, etc etc
Ben
Verstuurd vanaf mijn iPhone
> Op 18
We never had a Getting Started guide. We need one. And because it's so
hard for someone "in the know" not to assume knowledge, we may need
the help of some total n00bs to get this guide written -- to see where
they get stuck and waste time looking for answers, and write those
things in the
Hi,
> I can +1 on most of them, but isn't correct that the PPMC will need to all
> agree on these?
There need to reach consensus, that doesn’t mean all need to 100% agree but all
are OK with the proposed workflow.
>> When they wish to contribute, they can do so:
>> * Via a pull request
>> *
HI,
> 3.
> PMC should triage and assign the change to a committer. PMC may
> also review for conformance with the Inviolables If this review
> fails, the change is declined.
Most of the Apache projects I’m on let committers select what they what to
review and work on rather than being
Hi,
> We never had a Getting Started guide. We need one. And because it's so
> hard for someone "in the know" not to assume knowledge, we may need
> the help of some total n00bs to get this guide written -- to see where
> they get stuck and waste time looking for answers, and write those
> things
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?
I will not discuss git or github in this thread. I suggest you start a
new thread on that subject.
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
-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
: [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 lear
the emails about status and progress.
Ben
-Oorspronkelijk bericht-
Van: Gregory Nutt
Verzonden: woensdag 18 december 2019 20:31
Aan: dev@nuttx.apache.org
Onderwerp: Re: Getting Started (Was Re: [DISCUSS - NuttX Workflow])
Ben vd Veen has been working on a NuttX getting started book
ime
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 d
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
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?
>
>
Ben vd Veen has been working on a NuttX getting started book for a few
months. I don't know the current state. There was a channel on the old
NuttX Slack devoted to the book, but it has not been updated in a very
long time. Perhaps Ben could fill us in on the current state, progress,
and
> I'd prefer that the Getting Started guide should be reachable by one
> click from the front page of the NuttX website (which doesn't exist
> yet), so that a TOTAL newbie who hasn't even gotten the code yet can
> read and get a feel for what's involved.
Agree.
I wanted to point out that much of
On Wed, Dec 18, 2019 at 12:01 PM Gregory Nutt wrote:
> There is this: http://www.nuttx.org/doku.php?id=wiki:getting-started
> where the "external tutorials" is quite extensive:
> http://www.nuttx.org/doku.php?id=wiki:getting-started:external-tutorials
That's great but I think we need our own
Boards readme files contain all the information needed to get started
with a particular board.
Many do. They all should. They vary in quality. Some board README
files have no useful information at all; some have old information.
Some consist of only a few lines, some are thousands of
Boards readme files contain all the information needed to get started
with a particular board.
On Wed, Dec 18, 2019 at 5:01 PM Gregory Nutt wrote:
>
> On 12/18/2019 10:47 AM, Nathan Hartman wrote:
> > On Wed, Dec 18, 2019 at 11:04 AM David Sidrane wrote:
> >> What about the people who are just
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:
On 12/18/2019 10:47 AM, Nathan Hartman wrote:
On Wed, Dec 18, 2019 at 11:04 AM David Sidrane wrote:
What about the people who are just learning Nuttx? Simple is relative.
We never had a Getting Started guide. We need one. And because it's so
hard for someone "in the know" not to assume
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
On Wed, Dec 18, 2019 at 11:04 AM David Sidrane wrote:
> What about the people who are just learning Nuttx? Simple is relative.
We never had a Getting Started guide. We need one. And because it's so
hard for someone "in the know" not to assume knowledge, we may need
the help of some total n00bs
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
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
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
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/,
On Wed, Dec 18, 2019 at 9:05 AM Gregory Nutt wrote:
> 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
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
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
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.
Isn't this just another case where
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.
I agree. Let's not change that.
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
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!
No one should be held accountable for what the say in a bar 8-)
A lot depends on the nature of the coding standard change. If
On 12/18/19, 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
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.
I am also (very) opposed to combining repositories. Smearing
functionality is just bad system architecture. Separateness and
modularity is
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
r 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?
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
> 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"
>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 =
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
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
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
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.
87 matches
Mail list logo
