The 2 and 3 is to contrast HARD against EASY. This is so ALL of us can realize we are not suggesting doing what is expedient*, What is being suggested is doing what is right. I am having a really hard time to get you to see this is not about EASY. It is subtle.
>I don't know if my understanding of the proposal is correct (I think I've confused 2 and 3 a couple of times). But I can't imagine a problem with the testing/ repository that holds sub-modules. The user would not be impacted by such a thing in any. Yes they are an end-user needs to pull nuttx and apps at any instant in time and have them be in sync. *there is no intent to violate the inviolate -----Original Message----- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Wednesday, December 18, 2019 6:06 AM To: dev@nuttx.apache.org Subject: Re: [DISCUSS - NuttX Workflow] So I hope that we do not go to far down the github rabbit hole. At this level. Everytime we have tried to address and agree to the functional work flow, we get derailed by github technical implementation details. I think this discussion is relevant still, but we are on edge losing focus ont he functional workflow and talking only about github implementation (and have crossed the edge at times). > what advantage does in fact the submodule method bring? > > Even with a hat repository that contains two submodules (apps and nuttx), > you > will have to send separate pull requests for each submodule, right? There are three different concepts being discussed here that I think we should separate. I know that I get confused about which is which. 1. Two repositories apps/ and nuttx/ -- GOOD 2. One respository with apps/ and nuttx/ as folders -- VERY, VERY BAD 3. Three repositories, apps/, nuttx/ and, say, testing/. Where testing has the apps/and nuttx/ as submodules -- WORTH CONSIDERING Number 3 would simply be a mechanization to support the workflow. The end user would never clone it or need ever be concerned about it in any way. From the end-user point of view apps/ and nuttx/ are the only repositories. I don't know if my understanding of the proposal is correct (I think I've confused 2 and 3 a couple of times). But I can't imagine a problem with the testing/ repository that holds sub-modules. The user would not be impacted by such a thing in any. If there is no user impact and no smearing of architectural entities, then I retract bad things I said about sub-modules in any previous discussion. Greg
