On Fri, Dec 13, 2019 at 8:05 AM Gregory Nutt <spudan...@gmail.com> 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
