Hi Sebastien, I agree submodules are a PAIN! But I do not agree this is hard it is just more steps.
This why: Because on a busy project it will break the build and/or cause code to not get run. It will waist time debugging ghosts and creating problem posts to list of issues that are not reproducible. No matter what anyone thinks architecturally - There are dependencies from apps to nuttx and nuttx to apps. Two examples: 1 ) Change: CONFIG_EXAMPLE_IRBLASTER -> CONFIG_EXAMPLE_IR_BLASTER In all the defconfig files on nuttx then on apps push nuttx ->>>>>>>>You pull push apps Oh my code is broken it does not even run the ir blaster OR 2) Add a new OS syscall push apps ->>>>>>>>You pull push nuttx Oh the build is broken If you want to roll the dice you can - do your old work flow NOTHING is stopping you from it just check or the two repos not the knot repo do it all by hand. David -----Original Message----- From: Sebastien Lorquet [mailto:sebast...@lorquet.fr] Sent: Wednesday, December 18, 2019 2:58 AM To: dev@nuttx.apache.org Subject: Re: [DISCUSS - NuttX Workflow] 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. devs were sending patches for one of them. Now they send pull request instead. Better tracking, ability to fix while being reviewed... pull requests require branches, that will be annoying with submodules. This will still require separate pull requests for apps and nuttx. I have NEVER seen any contribution that really required an exactly atomic update to both repos. People often send patches for nuttx, and sometimes for apps. Why change that? Sebastien Le 18/12/2019 à 11:46, David Sidrane a écrit : >> 5 issue one pull request from your fork nuttx/apps to apache nuttx/apps >> master branch > Are you suggesting we have one repo NuttX with 2 folders apps and nuttx? > > That will simplify everything! - but I suspect we will receive STRONG > arguments against it. > > So you say "one pull request" > > Where? You have 2 repos. PR are against a single repo. > > This it what the Knot does. - It is the where > > On 2019/12/18 10:09:26, Alan Carvalho de Assis <acas...@gmail.com> wrote: >> Hi Liu, >> >> On Wednesday, December 18, 2019, Haitao Liu <liugu...@gmail.com> wrote: >>> How about just keep two separate git repositories (apps and nuttx >>> projects) instead >>> of add a parent knot repo with apps and nuttx as sub-modules? >>> As to jenkins CI, I haven’t found proper github plugin to get PRs from >>> multiple repos(especially PRs dependency in apps & nuttx ) in one >>> Jenkins >>> job. Before that, I wonder whether we could keep it simple and >>> directly, create >>> one jenkins job for apps and another jenkins job for nuttx to process >>> PR >>> trigger accordingly. Just make sure the jenkins pipeline or build >>> script >>> to sync both apps and nuttx repos, then pick the apps or nuttx PR to do >>> full build. >>> >>> Since nuttx and apps projects keeps same as before, developers adapt to >>> github workflow as usual: >>> 1 fork the official apache nuttx & apps projects in github >>> 2 git clone your fork projects locally >>> 3 edit locally and then git commit to local branch >>> 4 git push to your github fork nuttx/apps branch >>> 5 issue one pull request from your fork nuttx/apps to apache nuttx/apps >>> master branch >>> 6 jenkins CI auto-trigger: style check, build or test, if failed, go to >>> step 3, continue 3 ~ 7 >>> 7 PMC start to review PR, review ok, merge to master; or review failed, >>> go >>> to step 3, continue 3~7 >>> >>> Detailed info about GitHub workflow: >>> >> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests >> I agree! Using two repositores is better than creating submodules. >> >> We Just need to guarantee that users will clone both directories. The >> build >> system can do it when the user try to build without the ../apps. >> >> BR, >> >> Alan >>
