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
