Hi Justin, Great points. See below
On 2019/12/21 00:42:58, Justin Mclean <jus...@classsoftware.com> wrote: > Hi, > > 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 > infrastructure in the same releases may make that harder). > - This is a common scenario, a user is on an old version and needs to test > it, the new testing repo has been updated to work with teh latest release, > how do they test it? > > Thanks, > Justin >- This is a common scenario, a user is on an old version and needs to test it, >the new testing repo has been updated to work with teh latest release, how do >they test it? The test repo has submudules to the nuttx and apps. The master branch of testing is tied to master on apps and nuttx The release branch(s) of testing is tied to the release branch(s) on apps and nuttx Then it always works. However take nxtyle as an example. We ask submitter to run nxtyle on code to make sure the submission abides by the NuttX coding standard. If on day 94 the nxtyle finds an issue better then on day 12 of its life. A user may contribute a submission from a release that does not abides by the NuttX coding standard. This can be mitigated by keeping the style tools in a separate repo and asking dev to always stay on master of that repo. It also enables CI to always use the best nxtyle we have. Thus keeping master properly formatted. David
