I am continuing to accept changes to the (deprecated) NuttX repositories
on Bitbucket.org. Can someone please inform me when INFRA is ready to
instantiate the Apache Github repositories? I will then make the the
Bitbucket repositories read-only and prohibit forks and PRs. Let's try
to make
Hi, Greg. In ASF, usually the discussion about the committer candidates
should happen in the private@nuttx mailing list...
And also, the later vote for the new PPMC members and committers should
also happen in the private mailing list.
Okay... thanks! Still learning how things work.
Greg
Given that we want to open up the first committer spots to all
significant NuttX contributors, I made a list. I went through the top
20 or so all time contributors to NuttX and made a list of potential
committers. I have excluded already identified initial committers. I
have also excluded
I think submodules are a good way to go. That would leave us with 3 repos
as the core Apache NuttX. One for 'nuttx' which, is Greg suggests, should
always be exclusively the OS. One for 'apps'. And one for "linking" them
together, and for providing other NuttX infrastructure that may not be
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
No, the APPSDIR is configure-able. The default configurations all use
../apps/ for APPSDIR because there are not other apps in the
repositores. There have been many discussions on the old forums on how
to use custom applications, so I know end users actually do that. I
know, for example,
I think the below steps will do a an atomic tag/branch (Branch protections
may be needed as well)
Let's fully understand the release process before proposing a solution.
That sounds like a disaster.
However, it exemplifies why Submodules are evil but useful. A much simpler
approach is 2
Another thing to consider with the form of the release is that there an
many, many documents, Wikis, READMEs, HowTos, blogs, and videos
describing how to get started with NuttX. They all begin either 'git
clone' apps/ and nuttx/ (or download the tarballs). Changing that means
breaking a lot
The proposal looks good but we should also consider if we want to support
LTS maintenance releases containing bugfixed backported from mainline
It is the usual case that after you release code that within one or two
weeks after you release code, you discover embarrassing, gaping bugs. I
I think this emphasizes the point that we need to understand and
document a release requirements and procedure that is 100% consistent
with Apache requirements BEFORE we begin having low level discussions
on how to implement that release procedure. ...
I think that the first question we
So we definitely need to continue discussing what process changes to
these critical parts should undergo on their way into NuttX.
I think "continue" is generous. I don't think the discussion has
successfully even gotten off the ground. It is a looming crisis that is
going hit us like a
What is coming is 10-30 patches per day. When the Apache repositories
are set up. I will cease processing all changes. All PRs and patches
that I receive will be forwarded to this email. It is then the PPMC's
total responsibility to deal with them. Drop the ball for one day and
you will
I suggest that we really need to get all discussions, participation,
and contributions "under one roof" so to speak, at
dev@nuttx.apache.org. I think the Slack, the Google Group, the
LinkedIn Group, and any other forums that fragment participants,
should wind up soon. Whenever we reply to a
Has the SGA been filled in and submitted?
No, AFAIK, no SGA's have been filed. The wording here is
https://incubator.apache.org/guides/ip_clearance.html is unclear to me
under "Establishing Provenance". Contributor in this case refers to
copyright holders, I assume? The BSD headers list
I will send the SGA this weekend.
Also I am going to try to decouple better. It is not because I am
trying be the BDFL, it is just in my nature to "mother hen" software
projects. I will be detach and I will let the PPMP form itself with
less influence from me. I will try to continue to
Absolutely, Confluence would be great -- it'd be good place to create live
documents and tutorials that could evolve along with the code base...
The original plan was to integrate the existing DocuWiki at nuttx.org to
Confluence. If we begin using Confluence in an ad hoc way then I have
Hi, Justin
No, AFAIK, no SGA's have been filed. The wording here is
https://incubator.apache.org/guides/ip_clearance.html is unclear to me under
"Establishing Provenance". Contributor in this case refers to copyright
holders, I assume?
This only applies to code you are giving to the ASF
I am trying to get everything moved to apache.org, bit at a
time. Slack channels are shutting down, the word is slowly getting out
in the Google group. ..
I have removed the Slack application from most of my machines. I have
deactivated the accounts of all Inactive members. I will
So I created:
https://gitbox.apache.org/repos/asf/incubator-nuttx.git
https://gitbox.apache.org/repos/asf/incubator-nuttx-app.git
At nit: Historically, the directory is call apps/ not app/. That is the
way it is referred to in all of the documentation of and the
consciousness of NuttX
This doesn't seem to accept my LDAP credentials. Actually, it does. I can log
in but I don't seem to have authority to do anything.
Fixed - any NuttX committer will now be able to add/edit/comment on pages.
Opening it wider than that may attract spam.
Thanks!
I had to limit the
1.
https://lists.apache.org/thread.html/d58f8edd36eff155f061e84229dc035a71ea5cd7f0fa622bdd1a5dd0%40%3Clegal-discuss.apache.org%3E
Some general comments on that thread:
"It would be more accurate to say that Gregory Nutt *claims* copyright
over the whole code. However, the facts you
Alan,
Hmm, I think it could create some confusion because all docs and even the
build system expects to find the applications directory at ../apps/
Justin, do you mind to rename it from app to apps ?
You note that the git clone with no argument will create nuttx-app/ (or
nuttx-apps/), right?
Justin, do you mind to rename it from app to apps ?
I’ve created an incubator-nutty-apps one and asked Infra how to remove the
other one.
Hehe.. nutty-apps :-D
There are some pretty crazy applications in there.
G
I would be happy to push this forward. If there is a test space I can give
it a go this evening.
I’ve created a test space for you, if you need another just ask.
https://cwiki.apache.org/confluence/display/NUTTXTEST
There are only a few things that need to be brought in. From DocuWiki,
Apache supports a Slack. But it is only available for posting by
project members.
https://cwiki.apache.org/confluence/display/INFRA/Slack+Guest+Invites
No members can join into a single channel, but I am not sure exactly
how that works. The sign-up is here http://s.apache.org/slack-invite
Moving to the dev list.
Infra have go back to use and are willing to try it, but need someone to help.
Can someone here help?
I am the only person that knows that Wiki well. I don't believe that
there any anyone else that can help.
And I would be glad to help.
Greg
In the nuttx/ repository, there are a total 10,626 .c and .h files with copyrights in
the header (which should be all of them). Build-related files may also have
copyrights but are excluded here. I hold the copyright on 8,328 of them (78%). Sony
holds the copyright 401 files on (<4%) and
Perhaps it would be more efficient if you could forward my reply now.
I can add more if I am granted access.
Nevermind, I see that I don't have to join the list to post. Everything
should be there (although I do not see my long response yet).
Well it possible to use the code and both licenses are compatible. You would
generally want have people be involved and donate code rather than just taking
it.
You mean like Samsung did (and Motorola and project Ara an on and
on..). Samsung took the code from me first. I would not be
Communication stuff
I still see the slack channels, but they will go away? The IRC channel will get
back up in IRC apache? Linked in yes no? What the communication plan??!
Slack is shutting down. I tried to login earlier to deactivate myself
and it turns out that I was already deactivated.
So, could we just remove the original BSD header
from Samsung modified files and just keep their Apache license into
those file?
I don’t recommend we do that as they may of made changes or the files may of
changed since they copied them. They probably also used teh 3rd party header
not the
On 12/15/2019 3:19 PM, Brennan Ashton wrote:
Ftp or just a zip is fine. The media can be mixed with the pages or not.
However it's setup now should be fine. This is what I need from the docs of
the first converter stage.
I can tar up the data directories, put them in a google drive, and share
file. But no
issue we’ll fix this later and double check the dependancies.
And I removed it! It was only needed for a 2000-ish era board:
commit 897378bc292fc1ff5bbcd3ba616e2cafb8cd5f90
Author: Gregory Nutt
Date: Mon Dec 9 11:29:12 2019 -0600
Remove support for generation of RRLOAD
For easy hacks, I would suggest a minimal, trivial device driver that
just supports the the FBIO_UPDATE command (and any other command
unique to the hardware). This driver would have to lie in the
board-specific logic or else have an SPI interface passed to it during
initialization. Or
I need to understand more before I could comment.
I've implemented an ePaper driver under nxgl, but as some of you are
probably aware there needs to be an explicit redraw request to update
an ePaper display.
What is the interface to the ePaper device? Is it through a serial
interface? Or a
... I want to go the other way - when the application has decided that
a new display is 'stable', it requests for it to be put on the screen.
I don't understand what that means. Where is this new display?
Thanks. I understand better now.
This is very specific to this hardware. I don't think this should
involve the graphics system in such a device-specific way since this is
a hardware interfacing issue that has nothing to with graphics other
than a graphics device is involved. There are
Hmm...going further, the only way I see to deal with this at the nxgl
layer above the lcd structure itself is to add a nx_redraw with
corresponding NX_EVENT_REDRAWING/NXEVENT_REDRAWN event callbacks, but
that makes the nxgl layer device-aware...I don't see how it can't be
really, these
I don't really see any way to avoid this. Greg, any suggestions for a
better approach?
I would needed to understand how you are forming these displays, where
the display resides (in application memory), and how you are interfacing
from the "display" to hardware. I really don't have a clue
It means that some practical
details of the implementation of the display technology are 'leaking' up
into the graphics abstraction, but I don't really see a way to avoid it.
Only the application knows when it's permissible to take an extended
time to perform an update.
How are other
So, I think the path here is that I'll tidy up what I've done and then
I'll submit it for comment and kickabout, and see where we go from there.
If it is not too device specific, I can put it on a branch and we can
haggle through the details before merging it to master.
another patch fix warning: 'g_nullstring' defined but not used.
I don't see anything attached.
On 12/17/2019 9:03 AM, Dave Marples wrote:
How are other operating systems / graphics libraries handling this?
From what I've seen they mostly don't...you end up with a parallel
graphics subsystem built on top of an SPI. We can do better than that,
given that very little needs to be
On 12/17/2019 10:10 AM, Gregory Nutt wrote:
So, I think the path here is that I'll tidy up what I've done and
then I'll submit it for comment and kickabout, and see where we go
from there.
If it is not too device specific, I can put it on a branch and we can
haggle through the details
Great work. It looks great; and you made it look easy ;)
The bring-up was fast... but there were a few long nights I am sure.
When things are ready and stable, I will disable nutt.org and redirect
that to the Apache Confluence website. Just let me know when nuttx.org
is no longer
When things are ready and stable, I will disable nutt.org and redirect that to
the Apache Confluence website. Just let me know when nuttx.org is no longer
needed. nuttx.com will also be be redirected. Will that be at
https://nuttx.incubator.apache.org/ like the status page or
When things are ready and stable, I will disable nutt.org and redirect that to
the Apache Confluence website. Just let me know when nuttx.org is no longer
needed. nuttx.com will also be be redirected. Will that be at
https://nuttx.incubator.apache.org/ like the status page or
Justin, can we send the attachment to dev@nuttx.apache.org?
You can but it increases the chance the email will be marked as spam. I believe
we can ask Infra to modify that.
How do other projects accept patches? If there is a more standard way,
we should consider that.
Greg
Justin, can we send the attachment to dev@nuttx.apache.org?
You can but it increases the chance the email will be marked as spam.
I believe we can ask Infra to modify that.
How do other projects accept patches? If there is a more standard
way, we should consider that.
I find a lot of
Sounds good to me 8-)
On 12/17/2019 5:36 PM, Justin Mclean wrote:
Hi,
So the discussion on legal discuss has died down [1] and the SGA has been
filled. My reading of that legal thread is that you now OK to transfer
everything across. Code not owned by the Nuttx project can be worked as
We could still use bitbucket I think.
Many feature is added, here has the detailed information:
https://github.com/ARMmbed/littlefs/releases
Should we use dev mail list for patch until the github workflow is ready?
Thanks
Xiang
The current plan of record is to continue to use the
[Moved to the dev list. Was Re: Access to private email archive ].
People should send patches to dev@.
Other projects have additional emails, often user[s] and issues, often
many more: https://mail-archives.apache.org/mod_mbox/
I am personally used to having a one-email-for-everything,
The current NuttX project at https://bitbucket.org/nuttx/ consists of
five respositories. We will need to understand how each of these
repositories will be handled under Apache.
* nuttx/ This is the operating system. It is only the operating
system. It is complete and usable with no
+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
Did you get access? When I try to login, it tell me I don't have permission.
So, let see if you get the UWC working converting DocuWiki to Confluence.
I can help organizing the content to create better categories to let
users find it easily.
A little off topic: What are going to do with
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
Case in point: My $company uses a really awesome SCM: Apache Subversion :-)
All very large corporations I have worked for use commercial SCM
suites. GIT is a great thing for open source projects and small
businesses, but for those companies with essentially unlimited resources
you will often
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
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.
Yes, I can see you were up late working on this!
I also went through and manually cleaned the naming, obvious issues,
the usage case of
NuttX should depend upon particular tools in the user environment (other
than those minimal tools necessary for the build).
Forcing GIT on everyone would lose some users.
Greg
On 12/15/2019 7:48 PM, Gregory Nutt wrote:
Just a guess, but I think right now we receive 50 or so
But I think that someone from committer need convert patch to the
github pull request, and then pass all automatic check before
submitting the change.
To ensure the commit quality, nobody can bypass the workflow we will setup.
You are absolutely right. There is not difference between
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
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
Just a guess, but I think right now we receive 50 or so patches for each
PR. That is very deeply ingrained in NuttX userland.
On 12/15/2019 7:45 PM, 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
I am continuing to accept changes to the (deprecated) NuttX
repositories
on Bitbucket.org. Can someone please inform me when INFRA is
ready to
instantiate the Apache Github repositories? I will then make the the
Bitbucket repositories read-only and prohibit forks and
I think we need to ask our mentors what is the generally accepted
thing to do with the project's earlier incarnation.
100% agreed. We need guidance.
I don't think you need to get rid of the earlier incarnation of the
project. ...
Skimming the documents, it appears that ASF has no position on the
disposition of the earlier incarnations of the. I think that
maintaining them as mirrors of the Apache code would be best option
for the
I don't think you need to get rid of the earlier incarnation of the project. ...
Skimming the documents, it appears that ASF has no position on the
disposition of the earlier incarnations of the. I think that
maintaining them as mirrors of the Apache code would be best option for
the
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
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
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
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
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
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
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
On 12/19/2019 2:35 PM, Justin Mclean wrote:
Hi,
Do I understand you correctly? We can use the original google group and add a
user there with the dev@nuttx.apache.org?
Mailing list are archived / mirrored in serval places, here’s a couple:
https://lists.apache.org
] 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
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
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
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.
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
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
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
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
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
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
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.
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
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
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
+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, December 22
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
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
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
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.
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
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
1 - 100 of 1572 matches
Mail list logo
