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
Forwarded:
"David S. Alessio"
Subject Re: [DISCUSS - NuttX Workflow]
DateThu, 19 Dec 2019 00:33:00 GMT
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
Step 4
Ultimately, it is the committer who is responsible for assuring that
(1) the change is technically correct, complete, and of the highest
quality. And that (2) the change is consistent with all of the
principles of the Inviolables: The change must not violate the
portable POSIX
On 12/21/2019 1:32 PM, Gregory Nutt wrote:
As you can see, I have been tried to forward relevant emails from
this thread. There are at least two and maybe three that I cannot
find. ...
There is possibly a third email that I cannot find from David Sidrane
that had some thoughts about the
As you can see, I have been tried to forward relevant emails from this
thread. There are at least two and maybe three that I cannot find. ...
There is possibly a third email that I cannot find from David Sidrane
that had some thoughts about the work flow. I can't find it and I
don't
There is also this proposed change to the work flow that I did not
include only because I don't understand it.
Proposed Steps from Contribution to Commit
I think the work flow should be like this:
1.
Use git Pre-commit: on developers machine. To run Code-Style (CS)
and formatting
As you can see, I have been tried to forward relevant emails from this
thread. There are at least two and maybe three that I cannot find.
First there is the text which I appended to Nathan's workflow:
Proposed Work Flow
Proposed Steps from Contribution to Commit
I think the work flow
Haitao Liu
Subject Re: [DISCUSS - NuttX Workflow]
DateWed, 18 Dec 2019 09:51:45 GMT
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
Forwarded Message
Subject:Re: [DISCUSS - NuttX Workflow]
Date: Thu, 19 Dec 2019 13:09:10 -0500
From: Nathan Hartman
Reply-To: dev@nuttx.apache.org
To: dev@nuttx.apache.org
On Thu, Dec 19, 2019 at 8:30 AM Gregory Nutt wrote:
On Thu, Dec 19, 2019 at
Forwarded Message
Subject:Re: [DISCUSS - NuttX Workflow]
Date: Thu, 19 Dec 2019 12:32:31 -0600
From: Gregory Nutt
To: dev@nuttx.apache.org
I think only 5 emails in the whole list really address these functional
requirements.
Let me add a 6th... (Without
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 2
+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
+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
re
On 12/21/2019 11:00 AM, Gregory Nutt 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
We have no capability to test via CI at present. We don't even have the
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
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
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
David, Brennan,
Thanks for starting this David, I think you are the only person that
could have gotten us out of the run we are in.
We need to get this into a place where we can collaborate on it.
Brennan, Justin suggested that we use Confluence for document
collaboration. We have no
On Sat, Dec 21, 2019, 12:40 AM Disruptive Solutions <
disruptivesolution...@gmail.com> wrote:
> You would like te see some REQuirements would be addressed by some DevOps
> thoughts.. but C/C++ are still challenging here. And then the principle:
> automate where you can!
>
> (
>
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
You would like te see some REQuirements would be addressed by some DevOps
thoughts.. but C/C++ are still challenging here. And then the principle:
automate where you can!
( https://www.google.nl/amp/s/devops.com/devops-challenges-c-c-projects/amp/)
Also one would like that the code to be
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.
>
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)
23 matches
Mail list logo
