Interesting NuttX presentation coming up:
Making a robot controller from scratch
With NuttX, IoT.js, WebThing and more
https://fosdem.org/2020/schedule/event/iotnuttx/
Alan found that and posted this in the LinkedIn group. Worth re-posting
here.
Greg
How about this
Looks fine
Greg, please confirm you can receive attachments.
Got it!
[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.
I don't know if there are any problems with doing this with tags, but
we cannot do this which commits without eventually really mucking up
the history.
Commits must go in on direction. For the time being, I think it must
work like this:
* There must be no changes directly to the apache
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
We you can see the new repository is working fine.
I submitted the i2C driver for STM32G070/NUCLEO-G070RB that was added
to bitbucket.
Tomorrow I will do a get fetch from apache and force bitbucket to
exactly match the apache repository (after verifying that the recent
histories are the sa
[Cross posting to both the (deprecated) Google Group and to the Apache
dev list.]
This is to inform all users of and contributors to NuttX that there are
changes on the way; Some things will need be done differently
beginning as of now. The Apache NuttX repositories are online and are
now
They should be in sync now.
Those were probably created just after the transfer.
There was a window in time between when the time that Abdelatif's
bitbucket clone was updated and when when it was pushed to Apache.
For my point of view, the commits were pushed before the repositories
were
hould decide.
The Apache repository started out 3 commits behind the Bitbucket
repository:
commit 54d6a0768ccd0e386b67723cc1a24e9e9fff902a
Author: Daniel Pereira Volpato
Date: Fri Dec 20 13:07:31 2019 -0600
boards/arm/stm32f0l0g0/: Fix issues noted by nxstyle.
co
Alan, I see that you brought these changes into the Apache. I was
surpised to see that the same changes are in the gitbox.apache.org
repository are in the github.com/apache repositories. Can you please
clarify what you did here? Did you
* Modify https://gitbox.apache.org/repos/asf?p=incu
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 repos
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 repos
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
itbox, and also you can
accept PRs on github.
Gregory Nutt 于2019年12月21日周六 上午5:09写道：
[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.
Same answer. We need to clearly define how the workflow should behave
first. Then we will have a set of requirements that we can use to make
trade-offs against the design options.
With no requirements in hand, it is just people supporting their
favorite tools or implementations they are fami
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 othe
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
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.
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
That has already
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
That has alrea
And the patch is the same format and put on this mail address just like when we
were in the Google Group?
I would suggest holding off all changes and PRs until we get a proper
workflow in place. No one will act on them now.
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
I am finished. I will not review any further changes or make any
further commits
Greg
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.
You might as well just merge it to master now. I am out of the loop on
all further changes.
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
But to avoid we lose the confidence and contribution in the transition
phase, it's better that Greg has the special right to be the only
person who review and commit the code until the community agree and
setup the new workflow.
I suppose that the special period should be short and around sever
This is David's suggested workflow, but it still in the discussing or
voting process?
Before we get the approvement from community, we can't apply this
process now because its' unfailr to other upcomming potential
suggestion.
So my suggestion is still to keep the old process: Greg review and
c
In the transition phase, only you(Greg) can merge PR or create branch,
other PPMC member shouldn't touch the official repo.
So I think there isn't difference between bitbucket and apache? we
just change the repo location, no more change until the new workflow
setup.
Because of the recent expe
On 12/21/2019 8:38 AM, Abdelatif Guettouche wrote:
When I agreed to mange the commits through the transition period, that
was conditioned on continuint to use the bitbucket repository that only
I have access to, and then syncing the Apache repositories to the
bitbucket repository. That would wor
For opening a PR, usually you can just fork the repo and create a branch in
the forked repo, and then open a PR. It is not necessary to create a branch
in the original repo only for a PR.
You can open a branch for a big feature, which usually needs a lot of
commits and also a very long time be
I will merge nothing. I resign from the postion of review committer.
The PPMC must handle this not me. I don't do this any more.
On 12/21/2019 9:27 AM, David Sidrane wrote:
Greg,
Please merge these patches.
This is duplicate of the link and PR. I will close the PR and delete the
branch.
D
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 b
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 b
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 hav
Forwarded Message
Subject:Re: [DISCUSS - NuttX Workflow]
Date: Wed, 18 Dec 2019 11:55:46 -0500
From: Nathan Hartman
Reply-To: dev@nuttx.apache.org
To: dev@nuttx.apache.org
On Wed, Dec 18, 2019 at 11:18 AM Gregory Nutt wrote:
Requirements specification
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
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 3
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 plugin
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 shou
lures, ask the contributor to fix the problem and
resubmit push the changes. (This is automatic in the tooling of github.)
On 12/21/2019 1:26 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 c
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 recal
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
Now I remember, David was proposing a C beautifier to be used in the
work flow. I cannot find that one right now.
Related:
Gregory Nutt
Subject Re: [DISCUSS - NuttX Workflow]
DateWed, 18 Dec 2019 13:36:24 GMT
Option d) Make minimal coding standard changes that can be 100
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 i
There is no workflow definition. DavidS started a thread, but so far it has
only general principles, no work flow.
I for one struggle to “define a workflow” without using the vernacular of the
underlying tool (git + githug/gitlab/bitbucket). Best practices SW development
workflows, today
Those people with devops should coordinate in another thread and make
proposals for top-level functional to the broader audience.
We have enough smart and disciplined people here, I think we can do this.
We should be able to spec from the top-level (no tool speak) process down the
the nit
Those people with devops should coordinate in another thread and make
proposals for top-level functional to the broader audience.
We have enough smart and disciplined people here, I think we can do this.
We should be able to spec from the top-level (no tool speak) process down the
the nit
PM, Gregory Nutt wrote:
Those people with devops should coordinate in another thread and make
proposals for top-level functional to the broader audience.
We have enough smart and disciplined people here, I think we can do this.
We should be able to spec from the top-level (no tool speak
When I agreed to mange the commits through the transition period, that
was conditioned on continuint to use the bitbucket repository that only
I have access to, and then syncing the Apache repositories to the
bitbucket repository. That would work.
Didn't we agree on that?
I said I would do th
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 t
Can we do that for the PR that David created? (I mean applying it on
bitbucket and I bring it to github)
It would takes some agreement to do that. But I don't want to do that
either anymore. The more I think about not having to apply patches
everyday, the better I feel about it. I feel l
There is essential no change activity in the project. Normally there
are might be 50 changes per week, but I think that there were only 6
last week. That is good and bad. It is good because I don't see any
reason for the PPMC to fear it is going to overwhelmed by changes in
the near futur
-development-workflow-with-git-and-ci-cd-5e8916f6bece
Heads up and keep believing!
Maybe I should not share my thought, but like most of us I do not care what
other people think :-) I am just concerned..
A spectator
Ben
Verstuurd vanaf mijn iPhone
Op 22 dec. 2019 om 02:34 heeft Gregory Nutt
Writing directly into the repository was certainly the wrong thing at
the wrong time since I was tasked to maintain the repository. But I
relinquish both the task of personally reviewing and managing the flow
all changes. So now it is a fair thing to be address. Now I would say
what committe
0
I think is a terrible idea. Doing something for expediency usually is.
But I will go along with the group think.
On 12/22/2019 7:59 AM, Alin Jerpelea wrote:
+1
On Sun, Dec 22, 2019, 15:57 Xiang Xiao wrote:
+1.
It's impotant to let people start the contribution.
The committer could/sho
Did someone call a vote on this? This is all very confusing.
First, we have adopted the shorthand of +1 just to mean you agree with
something. That is not a vote and a little confusing in most contexts.
Votes should be formally called with [VOTE] in the subject. Otherwise,
how can I tell i
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
+1
(sorry, I couldn't help it)
On 12/22/2019 9:13 AM, 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, D
I thought I was being humorous in replying with +1. But [VOTE] is in
the title so I guess this is a real, binding vote. That wasn't clear
from the text. I am so confused. Anway, my +1 vote still stands, just
not as funny anymore.
On 12/22/2019 9:14 AM, Gregory Nutt wrote:
+1
(sor
Removing the initial [VOTE] in an attempt at removing ambiguity
(although [VOTE] is still in the tile).
Let's dispense with the ALL ambiguity
We should assume if it does not say [VOTE] it is not a vote?
A follow on questions is who can call a binding vote? I searched apache
a little, but did
Should the [VOTE] phase also be preceded by a [DISCUSS] phase so that
people can have a chance to discuss, debate, haggle, argue, first?
Calling a vote out the blue leaves people in a position of having to
make a decision cold.
On 12/22/2019 9:26 AM, Gregory Nutt wrote:
Removing the initial
I thought I was being humorous in replying with +1. But [VOTE] is in
the title so I guess this is a real, binding vote. That wasn't clear
from the text. I am so confused. Anway, my +1 vote still stands,
just not as funny anymore.
You did not mention how long the vote will be open for.
I thought I was being humorous in replying with +1. But [VOTE] is in
the title so I guess this is a real, binding vote. That wasn't clear
from the text. I am so confused. Anway, my +1 vote still stands,
just not as funny anymore.
You did not mention how long the vote will be open for.
Let's get everyone's thoughts on the table
I did not call for a vote because I did not think I could as I'm just a
community member, I would like my proposal formally voted it on as is.
As for the two concerns that I saw raised.
1) The timeline. Two weeks over the holiday to come to a formal
1) The timeline. Two weeks over the holiday to come to a formal
agreement
is going to be tough and I also don't think just because we have a path
forward people will stop caring about proposing a better solution. From
what I'm seeing the longer term proposal will likely get into the
weeds of
Let's get everyone's thoughts on the table
I suppose that we should keep the discussion for 72 hours then call the
vote. We need to allow time for everyone to comment and with the
holidays, we may not be able to get good feedback. Should we still call
a vote if people are not participatin
I don't think that were will be much that has to be acted on during
the holidays. And, in any event, I would rather see a backlog of work
build up than to to see an interim, wrong workflow put in place. Doing
things right is more important that doing things quickly.
I would add that I do no
Hopefully someone with technical writing skills will volunteer to read that
email and start working on that document. If not, I'll do it, but it will
be delayed because I am completely swamped right now.
I think that the other people most active in the discussion are DavidS
and myself, but f
Hopefully someone with technical writing skills will volunteer to
read that
email and start working on that document. If not, I'll do it, but it
will
be delayed because I am completely swamped right now.
I think that the other people most active in the discussion are DavidS
and myself, b
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 a
There are several things I don't like about this proposal:
- It is in complete conflict with everything we have discussed about
the commit workflow
- I think is is suggest out of panic. We have plenty of times to do
things right or to do things better. There will be no pressing nee
There are several things I don't like about this proposal:
- It is in complete conflict with everything we have discussed
about the commit workflow
- I think is is suggest out of panic. We have plenty of times to
do things right or to do things better. There will be no pressi
ibute my
code.
--Brennan
On Sun, Dec 22, 2019, 3:46 PM Gregory Nutt wrote:
There are several things I don't like about this proposal:
- It is in complete conflict with everything we have discussed about
the commit workflow
- I think is is suggest out of panic. We have ple
I will be stepping away from all further discussion on the work flow topic as I
have soured on it and don't have a real vote beyond proposing it.
You are lucky that you have that option. I would too if it were
possible. This no way that anyone should have to waste there life.
But the #1
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 dela
Forwarded Message
Subject:[nuttx] [PATCH] doubt about fwrite
Date: Sun, 22 Dec 2019 18:30:04 -0800 (PST)
From: wei peng
Reply-To: nu...@googlegroups.com
To: NuttX
hi~
I connected the target board to terminal via "telnet" , in some cases
the terminal
Check the configuration that you are using. What is the UART used in
the NuttX configuration for the serial console? What is the UART that
connects to the debug port?
Do you have a jtag debugger? There should be instructions in the README
explaining how to single step into the OS. You shou
My question is:
Should I be able to see a NSH console on the debug serial port? Or the
USB serial port? I don't see either devices when I look at the host
system's /dev/ directory.
You would have to look at the SERIAL_CONSOLE setting in the
configuration file to find out. I don't recall.
The danger of what is happening now is that it will become grandfathered in
with no proper workflow in place, no proper criteria for processing
changes, and no clear documentation that helps committers or the public to
contribute.
We have to decline any attempt to include an test framework co
The danger of what is happening now is that it will become grandfathered in
with no proper workflow in place, no proper criteria for processing
changes, and no clear documentation that helps committers or the public to
contribute.
If that comes to pass, I think I would be forced to resign. Ap
Make sure you compile with debug info enabled and no optimization. Then, since
you mentioned you have a Segger J-Link JTAG probe, I highly recommend you use
Segger’s debugger Ozone (free J-Link probes) — you’ll be able to easily
single-step and determine what’s going wrong…
If you have a J-L
Two questions:
1 Who will apply the patches?
2 Can we use and merge a PR that has been reviewed?
You are basically asking for the workflow requirements.
Agreed.. It is painful and awkward and I am not so optimistic at the
moment. We will have to give it more time and see if people and learn
to cooperate in groups or not.
Also, I did not see a notification that the BB repositories had been frozen.
https://groups.google.com/forum/#!topic/nuttx/
I think the process should be as simple as possible, and improved later. Just
select the absolute bare minimum that could start to work and discard everything
else so this project can work again.
Depends on what you mean by simple. Using some less-than-simple tools
can make the workflow ver
Brennan created a page in the Confluence for the workflow document. I
know that only committers can edit the Confluence wiki directly but
that is not a problem: Anyone can write some text and email it to this
list, and a committer can edit it into the Confluence page. (Hint:
People who particip
..., but I'm down to this last missing function:
void up_usbinitialize(void)
Defined here:
$ grep -r up_usbinitialize arch/arm/src/sam34
arch/arm/src/sam34/sam_udp.c: * Name: up_usbinitialize
arch/arm/src/sam34/sam_udp.c:void up_usbinitialize(void)
arch/arm/src/sam34/sam_udp.c: * in when up_
I want to use the STANDBY mode in Power Management in the Nucleo-L432KC.
Now I am reading that in the STM32 Power Management is implemented.
What is the best way to get this working for the L432KC? I see that in arch
there are some power routines implemented. The standby register settings
"loo
I want to use the STANDBY mode in Power Management in the Nucleo-L432KC.
Now I am reading that in the STM32 Power Management is implemented.
What is the best way to get this working for the L432KC? I see that
in arch
there are some power routines implemented. The standby register settings
"l
changes I made:
https://github.com/apache/incubator-nuttx/compare/master...adamfeuer:feature/arduino-due-ethernet-over-usb
I guess I need to debug this too. :) Any tips? Did I do something
wrong with these modifications?
cheers
adam
On Mon, Dec 23, 2019 at 11:43 AM Gregory Nutt <mailto:s
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 commi
see the size_t is unsigned cannot be negative. that is the problem.
i think if the terminal is close,the "size_t fwrite()"function should
return a negative number,and the nsh_catfile should be broken.
That is not the way that fwrite returns errors. If an error occurs
fwrite returns fewer ite
An alternative way could be make master/trunk branch a dev branch and allow
all PRs to checked in, at the same time, maintain a stable branch which you
can cut release (as release manager) and pick up PRs that you carefully
reviewed. - This is the Apache way and I guess can achieve the same goa
Also, is there a way to take a PR against master and apply it as a branch?
I generally do that by taking the PR as a patch, then applying the patch
on a branch.
But it looks like you can do that with github:
https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changi
Also, is there a way to take a PR against master and apply it as a
branch?
I generally do that by taking the PR as a patch, then applying the
patch on a branch.
But it looks like you can do that with github:
https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/cha
I think we should strive to keep master as close to "releasable" as
possible at all times, do development on dev branch(es), and create release
branches to which changes are only made by backporting from master. I think
this is closer to a CI/CD (Continuous Integration / Continuous Delivery)
st
Git's claim to fame is supposed to be the cheapness of branches. What if
each PR becomes its own branch and then it either: (a) gets worked on, (b)
applied to master, or (c) deleted?
I think that would work fine. We need to verify that we can actually
change the PR base, but if so that woul
If they are related / dependent on each other, then I think those
kinds of patchsets should be encapsulated in one branch.
The need to be applied and committed in sequence. Sometimes the final
patch is the one that fixes the coding style. This is inherently very
manual.
If they are related / dependent on each other, then I think those
kinds of patchsets should be encapsulated in one branch.
The need to be applied and committed in sequence. Sometimes the final
patch is the one that fixes the coding style. This is inherently very
manual.
They need to be
I don't want the job so I have no problem going back the way things were.
I would ask only the we avoid controversial workflow-related commits
until we have workflow requirements requirements in place. We cannot
deal with that kind of power politics while we are trying to get this
fragile gro
There have been quite a few NuttX users who have been put of by the
volume and content of emails on this list. December is not quite over
and there have been close to 850 emails so far this month. And the
majority of the community is only interested is discussion technical
issues and do not e
901 - 1000 of 1751 matches
Mail list logo
