Re: Atomic git tagging (was RE: Project Emails)
Hi all, I am against submodules ! If we implement submodules things will be harder on downstream projects we guided downstream projects to integrate their own apps folder and include our apps in their apps http://www.nuttx.org/doku.php?id=wiki:nshhowtos:external-applications Regards Alin On Fri, Dec 13, 2019 at 10:12 AM David Sidrane wrote: > 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 >
Re: Atomic git tagging (was RE: Project Emails)
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 no longer login -- except to deactivate members as they become inactive. When all members are dactivated, I will delete the Slack altogether. People just have to stop using it and I will assure that it goes aware in its entirety. Greg
Re: Atomic git tagging (was RE: Project Emails)
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 (it’s actually not a transfer of copyright but permission to use), so this would only be the code owned by the NuttX project. It doesn’t include 3rd party code in the repo. The headers on those files owned by NuttX will change, but the headers of any 3rd party code will need to stay the same. I think the first step if for you to fill out a SGA and will discuss on legal discuss if anything else is needed. I think because you were the only person with commit right and the headers with your copyright that’s all that would be required. There are several files that will require corporate CLAs, I think, since the copy right holders are businesses like Sony or Pinecone. That’s not required as they are 3rd party files and belong to someone else. CCLA in general are not needed by the ASF, they are there because some companies require them for their employees to be able to work on OS software. The signed SGA has been sent to secret...@apache.org. I do you yet have any confirmation. So I think we can arrange the transfer of the repositories as soon as possible. Thanks for all of your help. We really need it! Greg
Re: Atomic git tagging (was RE: Project Emails)
On 12/13/19, Justin Mclean wrote: > Hi, > >> Do you know know project which did it in the past? > > Not from DocuWiki that I’m aware of. A search of the entire ASF mail > archives [1] didn’t find anything. > > Let wait until Infra get back to us - that may take a day or two. > Right, thank you again. BR, Alan
Re: Atomic git tagging (was RE: Project Emails)
Hi, > Do you know know project which did it in the past? Not from DocuWiki that I’m aware of. A search of the entire ASF mail archives [1] didn’t find anything. Let wait until Infra get back to us - that may take a day or two. Thanks, Justin 1. https://lists.apache.org/search.html
Re: Atomic git tagging (was RE: Project Emails)
Hi Justin, On 12/13/19, Justin Mclean wrote: > Hi, > >> It appears there are a converter from DocuWiki to Confluence: >> https://community.atlassian.com/t5/Answers-Developer-Questions/how-to-import-quot-dokuwiki-quot-to-confluence/qaq-p/526583 > > Yep I noted that on the JIRA. > How could help in this process to migrate the DocuWiki? Do you know know project which did it in the past? BR, Alan
Re: Atomic git tagging (was RE: Project Emails)
Hi Greg, On 12/13/19, Gregory Nutt wrote: > >> 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 > some concern that it will interfere with the clean port of the existing > Wiki. My hope is that we could have a clean Confluence website. Is > there reason for me to be concerned? > It appears there are a converter from DocuWiki to Confluence: https://community.atlassian.com/t5/Answers-Developer-Questions/how-to-import-quot-dokuwiki-quot-to-confluence/qaq-p/526583 BR, Alan
Re: Atomic git tagging (was RE: Project Emails)
Hi, I really don’t think there will be any issues doing both in parallel so I’ve created a confluence space here: https://cwiki.apache.org/confluence/display/NUTTX > I have heard that the INFRA team has some special kung-fu for importing Wikis > into confluence. I hope they can handle an old DocuWiki site. > > Is there any way that could be expedited? For thing like this the process is to raise an JIRA ticket for Infra. I’ve just raised one here: https://issues.apache.org/jira/browse/INFRA-19570 Thanks, Justin
Re: Atomic git tagging (was RE: Project Emails)
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 help when I can, but the PPMC must sink or swim based on the focus and motivation of the people who wanted to be members, not on my urging. If I am successful, you will hear less from me on these topics. Greg On 12/13/2019 5:17 PM, Justin Mclean wrote: Hi, 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 (it’s actually not a transfer of copyright but permission to use), so this would only be the code owned by the NuttX project. It doesn’t include 3rd party code in the repo. The headers on those files owned by NuttX will change, but the headers of any 3rd party code will need to stay the same. I think the first step if for you to fill out a SGA and will discuss on legal discuss if anything else is needed. I think because you were the only person with commit right and the headers with your copyright that’s all that would be required. There are several files that will require corporate CLAs, I think, since the copy right holders are businesses like Sony or Pinecone. That’s not required as they are 3rd party files and belong to someone else. CCLA in general are not needed by the ASF, they are there because some companies require them for their employees to be able to work on OS software. Thanks, Justin
Re: Atomic git tagging (was RE: Project Emails)
Hi, > 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 some > concern that it will interfere with the clean port of the existing Wiki. I don’t think there will be any issues along those lines, any new pages can be moved into an any imported space. Thanks, Justin
Re: Atomic git tagging (was RE: Project Emails)
Hi, > 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 (it’s actually not a transfer of copyright but permission to use), so this would only be the code owned by the NuttX project. It doesn’t include 3rd party code in the repo. The headers on those files owned by NuttX will change, but the headers of any 3rd party code will need to stay the same. I think the first step if for you to fill out a SGA and will discuss on legal discuss if anything else is needed. I think because you were the only person with commit right and the headers with your copyright that’s all that would be required. > There are several files that will require corporate CLAs, I think, since the > copy right holders are businesses like Sony or Pinecone. That’s not required as they are 3rd party files and belong to someone else. CCLA in general are not needed by the ASF, they are there because some companies require them for their employees to be able to work on OS software. Thanks, Justin
Re: Atomic git tagging (was RE: Project Emails)
> Is there reason for me to be concerned? Unfortunately, yes. As much as I like Confluence, if not properly organized and managed, it can quickly grow into an unnavigable mess. I suppose it's like anything else we do, it requires a process and disciplined maintainer... On Fri, Dec 13, 2019 at 2:42 PM Gregory Nutt wrote: > > > 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 > some concern that it will interfere with the clean port of the existing > Wiki. My hope is that we could have a clean Confluence website. Is > there reason for me to be concerned? > > > >
Re: Atomic git tagging (was RE: Project Emails)
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 some concern that it will interfere with the clean port of the existing Wiki. My hope is that we could have a clean Confluence website. Is there reason for me to be concerned?
Re: Atomic git tagging (was RE: Project Emails)
Absolutely, Confluence would be great -- it'd be good place to create live documents and tutorials that could evolve along with the code base... On Fri, Dec 13, 2019 at 2:02 PM Justin Mclean wrote: > Hi, > > > So where in Apache is an appropriate place to put shared documents, the > Apache public equivalent of my shared drive? I have been trying to scare > people into action on this workflow here for days now, but I guess this a > brave group or just completely blind to what is coming. > > Best place is confluence. We would need to set up a space for NuttX but > that’s easily done. Do you want me to go ahead and do that? > > Thanks, > Justin
Re: Atomic git tagging (was RE: Project Emails)
WRT to this build issue, it used to work without a git repo. Disclaimer:
I responsible for the original commit, a portion of which Greg reverted
today...
This is a good opportunity to discuss a larger topic -- this is just one
instance of a class of problems that can be minimized [or even avoided]
with the proper process.
I believe that process should be based on the best practices of Bitbucket,
Github, and git. I may be stating the obvious here, but I'd like to
suggest the following few simple rules:
1. Master should always build and, to the extent possible, "just work
right."
2. all development happens on a specific development branch for one
particular feature or bug. Features are developed on a branch named
"feature/". Bug fixes are developed on a branch named
"bugfix/". Branches and commits must be coherent with
minimal coupling.
Note: This is important so that commits can be cherry-picked into
other branches and back-ported as hotfixes to previous releases.
3. A pull request triggers a review (review committees TBD according to
domain). A successful review might be N approvals and no rejections. In
any case, the testing, debate, and correction happens on that branch before
merge.
4. releases could be managed similarly, as a branch off of Master, i.e.
"release/9.1" (we're at 8.2.* IIRC). If a bug is then discovered in 9.1,
a branch "hotfix/some-silly-bug" would be taken off "release/9.1"
Comments? [donning flame retardant suit]
Cheers,
-david
On Fri, Dec 13, 2019 at 1:23 PM Nathan Hartman
wrote:
> To add to the patch-to-merge workflow discussion, an anecdote.
>
> Earlier today I jokingly wrote "For the build system we should
> require more PMC votes than we have PMC members!!"
>
> Soon after, I grabbed the latest updates and tried to build my
> configurations and... the build was broken!
>
> I wrote:
>
> [[[
>
> Uh oh, commit 1c91aec6ae77b49608741e5aa30b8b6876017934 ("tools/ and
> fs/procfs: Simplify .version file generation") breaks the build if
> not in a git clone:
>
> $ make
> Create .version
> fatal: not a git repository (or any parent up to mount point /home/nate)
> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
> Missing versioning information
> USAGE: tools/version.sh [-d|-h] [-b ] [-v ]
>
> Try 'tools/version.sh -h' for more information
> make: *** [tools/Makefile.unix:266: /home/nate/nuttx/.version] Error 1
>
> If git is not available or building a copy of NuttX which is not a git
> clone, the create version logic should degrade gracefully in a way
> that does not break the build!
>
> ]]]
>
> Thankfully, Greg fixed this at warp speed with commits
> 3e4450e2376bb99da2ed5a3f0380044ce868e564 and
> 10b8c01abfa58276f006c282e1d88481fb0a4a8e.
>
> The point is, though, that this is precisely why we need to qualify
> what gets into the system. I feel pretty strongly that we can be
> flexible with things like drivers, hacking on architectural support
> for new chips and boards, etc. The impact of bugs or incomplete code
> there will be minimal and those are easy to catch and fix. I would
> like to make it easy for contributors to get their code out there and
> to feel like there's incentive to contribute, and not to put too many
> roadblocks in the way that would become a deterrent for contributors.
>
> BUT!!
>
> The core of the OS and the build system need the highest level of
> qualification. Screwups there are really disruptive!
>
> Problems in the build system might quickly become apparent.
>
> Problems in the core OS could go undetected until intermittent
> problems that are extremely hard to trace appear in the field. Since
> NuttX goes to places like space, "in the field" might be kind of,
> slightly, REALLY far away!
>
> So we definitely need to continue discussing what process changes to
> these critical parts should undergo on their way into NuttX.
>
> Cheers,
> Nathan
>
Re: Atomic git tagging (was RE: Project Emails)
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 only copy right holders and authors. I suppose on the copyright holder can contribute software. Often there are numerous authors but only one copyright holder. Well, the good news is this will slow things down quite a bit so next is probably not the week that the Tsunami hits. There are several files that will require corporate CLAs, I think, since the copy right holders are businesses like Sony or Pinecone. The PPMC needs to take this up and coordinate it.
Re: Atomic git tagging (was RE: Project Emails)
Hi, > that we are playing chicken with putting critical processes in place and > making the transition to Apache repositories. That transition supposed to > happen next week, right? It happens when the PPMC decided for it to happen. But first the SGA needs to de accepted [1] and then we may need to talk about if we need ICLA from the contributors or not.[2] Has the SGA been filled in and submitted? Thanks, Justin 1, https://www.apache.org/licenses/contributor-agreements.html#grants 2. https://www.apache.org/licenses/contributor-agreements.html#clas
Re: Atomic git tagging (was RE: Project Emails)
Hi, > So where in Apache is an appropriate place to put shared documents, the > Apache public equivalent of my shared drive? I have been trying to scare > people into action on this workflow here for days now, but I guess this a > brave group or just completely blind to what is coming. Best place is confluence. We would need to set up a space for NuttX but that’s easily done. Do you want me to go ahead and do that? Thanks, Justin
Re: Atomic git tagging (was RE: Project Emails)
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 be behind 10-30 commits. Drop the ball for ten more days and you will be 100-300 commits behind. That will be a crisis! There are slower times and busier times for commits. It changes like the seasons. It changes during the week as well. Fridays, Saturdays, and Sundays are usually lighter. Today, Friday the 13th, there were only 8 commits.
Re: Atomic git tagging (was RE: Project Emails)
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 Tsunami in just a handful of days. And there seems to be no focused concern. There is feeble attempt at work flow document on a shared Google drive (I just gave you access). But there seems to be no interest. It is in terrible shape, it is incomplete and unread-able. has had only three edits since it was created two weeks ago. Clearly a lack of interest in digging in. So where in Apache is an appropriate place to put shared documents, the Apache public equivalent of my shared drive? I have been trying to scare people into action on this workflow here for days now, but I guess this a brave group or just completely blind to what is coming. 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 be behind 10-30 commits. Drop the ball for ten more days and you will be 100-300 commits behind. That will be a crisis!
Re: Atomic git tagging (was RE: Project Emails)
To add to the patch-to-merge workflow discussion, an anecdote.
Earlier today I jokingly wrote "For the build system we should
require more PMC votes than we have PMC members!!"
Soon after, I grabbed the latest updates and tried to build my
configurations and... the build was broken!
I wrote:
[[[
Uh oh, commit 1c91aec6ae77b49608741e5aa30b8b6876017934 ("tools/ and
fs/procfs: Simplify .version file generation") breaks the build if
not in a git clone:
$ make
Create .version
fatal: not a git repository (or any parent up to mount point /home/nate)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
Missing versioning information
USAGE: tools/version.sh [-d|-h] [-b ] [-v ]
Try 'tools/version.sh -h' for more information
make: *** [tools/Makefile.unix:266: /home/nate/nuttx/.version] Error 1
If git is not available or building a copy of NuttX which is not a git
clone, the create version logic should degrade gracefully in a way
that does not break the build!
]]]
Thankfully, Greg fixed this at warp speed with commits
3e4450e2376bb99da2ed5a3f0380044ce868e564 and
10b8c01abfa58276f006c282e1d88481fb0a4a8e.
The point is, though, that this is precisely why we need to qualify
what gets into the system. I feel pretty strongly that we can be
flexible with things like drivers, hacking on architectural support
for new chips and boards, etc. The impact of bugs or incomplete code
there will be minimal and those are easy to catch and fix. I would
like to make it easy for contributors to get their code out there and
to feel like there's incentive to contribute, and not to put too many
roadblocks in the way that would become a deterrent for contributors.
BUT!!
The core of the OS and the build system need the highest level of
qualification. Screwups there are really disruptive!
Problems in the build system might quickly become apparent.
Problems in the core OS could go undetected until intermittent
problems that are extremely hard to trace appear in the field. Since
NuttX goes to places like space, "in the field" might be kind of,
slightly, REALLY far away!
So we definitely need to continue discussing what process changes to
these critical parts should undergo on their way into NuttX.
Cheers,
Nathan
Re: Atomic git tagging (was RE: Project Emails)
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, that many users do not use NSH (which the most popular thing in apps/). Consider also: http://www.nuttx.org/doku.php?id=wiki:nshhowtos:external-applications http://www.nuttx.org/doku.php?id=wiki:nshhowtos:custom-appsdir +1. Case in point: Some of my boards use NSH, others don't, depending on the application. Many people people using NuttX in deeply embedded control systems with no possibility of a UI use NuttX with no NSH, and presumably with no apps/ since there is little in apps/ relevant to that kind of system. apps/ needs to be an option that you can use with complete flexibility with apps/, with contained apps, with extended apps/, with replacement apps/, ... basically as described in the first reference above. The PPMC should make all decisions based on sound reasonbing. I personally would be very opposed to anything which corrupts the clean OS architecture by coupling it with any application. +1. It is *crucial* to keep that clean OS architecture. More below... Absolutely. We are all professionals. That is a fundamental responsibility of being a professional. Before we can ever make a release, we first have to answer the question of how do changes even get committed? This is a question of project policies, which should be discussed, decided upon, and very importantly: documented. We shouldn't rush to come up with a policy. Rather, we should study the policies of other Apache.org projects to get some ideas first. For example, are we CTR (Commit Then Review) or RTC (Review Then Commit)? Do we have a mix of these two types depending on the area of the repository? Perhaps drivers (like SPI drivers for a particular MCU) or architectural support (where it is likely that only one of us has expertise in that particular architecture) are CTR, whereas changes that affect the core OS or build system require RTC with a vote and three +1s and no -1s to get merged. (For the build system we should require more PMC votes than we have PMC members!! Just kidding.) I wonder if it would be of value to have some dialog with Mynewt. They deal with releases from multiple GIT repositories and have a lot in common with NuttX. In my contacts with Mynewt folk in the past, they were friendly and helpful. We do have to come up with some basic workflow for how a patch that appears in dev@nuttx.apache.org gets reviewed, verified, approved and incorporated onto the master. The time when we need that basic workflow is days away. We need to agree on the sequence of events that must occur (not on tools and implementations of those events). It is likely that we might have to have a sub-team managing the workflow manually until we are fully tooled up. Greg
Re: Atomic git tagging (was RE: Project Emails)
On Fri, Dec 13, 2019 at 8:05 AM Gregory Nutt wrote: > Let's fully understand the release process before proposing a solution. +1. More below... > 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, that many users do not use NSH (which the most > popular thing in apps/). > > Consider also: > > http://www.nuttx.org/doku.php?id=wiki:nshhowtos:external-applications > http://www.nuttx.org/doku.php?id=wiki:nshhowtos:custom-appsdir +1. Case in point: Some of my boards use NSH, others don't, depending on the application. More below... > The PPMC should > make all decisions based on sound reasonbing. I personally would be > very opposed to anything which corrupts the clean OS architecture by > coupling it with any application. +1. It is *crucial* to keep that clean OS architecture. More below... > This discussion is really all about a proposed shortcut for a release (a > release that we do not yet understand). I would say two things about > that: (1) I don't think we should take shortcuts to releases (and we > certainly should not sacrifice the integrity of the OS just to use a > shortcut) -- that is one of the "enemies" of good system design. And > (2) we really need to understand and document the release procedure > BEFORE we begin proposing solutions, especially solutions that have long > reachable negative impacts. > > Tradeoffs are a necessary part of getting things done and all trade-offs > involve compromising between two things, one that you like and one that > you dont like. We may have to compromise things to achieve what we > want, but now is not the time. But remember that "premature > optimization is the root of all evil." Before we can ever make a release, we first have to answer the question of how do changes even get committed? This is a question of project policies, which should be discussed, decided upon, and very importantly: documented. We shouldn't rush to come up with a policy. Rather, we should study the policies of other Apache.org projects to get some ideas first. For example, are we CTR (Commit Then Review) or RTC (Review Then Commit)? Do we have a mix of these two types depending on the area of the repository? Perhaps drivers (like SPI drivers for a particular MCU) or architectural support (where it is likely that only one of us has expertise in that particular architecture) are CTR, whereas changes that affect the core OS or build system require RTC with a vote and three +1s and no -1s to get merged. (For the build system we should require more PMC votes than we have PMC members!! Just kidding.) As an example, here's the document from my other Apache.org project: https://subversion.apache.org/docs/community-guide/ That document covers coding conventions, release procedures, voting on changes, and many other policy issues. We can use that as a template of what needs to be covered in our document. Nathan
Re: Atomic git tagging (was RE: Project Emails)
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 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) 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, that many users do not use NSH (which the most popular thing in apps/). Consider also: http://www.nuttx.org/doku.php?id=wiki:nshhowtos:external-applications http://www.nuttx.org/doku.php?id=wiki:nshhowtos:custom-appsdir I don't think simple is particularly strong argument. First question I would poll the community is: "How many of you do not use the apps folder?" This is an internal architectural decision and I don't think it is an issue that involves any kind of community vote. That is how we got Trump, we get a dictatorship of the uninformed majority. The PPMC should make all decisions based on sound reasonbing. I personally would be very opposed to anything which corrupts the clean OS architecture by coupling it with any application. This discussion is really all about a proposed shortcut for a release (a release that we do not yet understand). I would say two things about that: (1) I don't think we should take shortcuts to releases (and we certainly should not sacrifice the integrity of the OS just to use a shortcut) -- that is one of the "enemies" of good system design. And (2) we really need to understand and document the release procedure BEFORE we begin proposing solutions, especially solutions that have long reachable negative impacts. Tradeoffs are a necessary part of getting things done and all trade-offs involve compromising between two things, one that you like and one that you dont like. We may have to compromise things to achieve what we want, but now is not the time. But remember that "premature optimization is the root of all evil."
