From mboxrd@z Thu Jan 1 00:00:00 1970 From: daniel.sangorrin@toshiba.co.jp (Daniel Sangorrin) Date: Mon, 7 Jan 2019 15:45:07 +0900 Subject: [cip-dev] [RFC] isar-cip-core In-Reply-To: <1be77add-abce-e4d2-4d47-d371238390bf@siemens.com> References: <00ed01d4a620$26921860$73b64920$@toshiba.co.jp> <1be77add-abce-e4d2-4d47-d371238390bf@siemens.com> Message-ID: <010501d4a654$87230570$95691050$@toshiba.co.jp> To: cip-dev@lists.cip-project.org List-Id: cip-dev.lists.cip-project.org > -----Original Message----- > From: Jan Kiszka > Sent: Monday, January 7, 2019 2:41 PM > To: Daniel Sangorrin ; 'cip-dev' > Subject: Re: [cip-dev] [RFC] isar-cip-core > > Hi Daniel, > > On 07.01.19 01:30, Daniel Sangorrin wrote: > > Hi Jan, > > > > Thanks for uploading isar-cip-core. > > > > As you noticed[1], https://gitlab.com/cip-project/cip-core/ contains a folder "deby". I created that folder with > the intention of adding "isar" and other tools' metadata at the same folder level. > > > > cip-core/ <-- git repo > > deby/ <-- deby metadata > > isar/ <-- isar metadata > > eid/ <-- eid metadata > > > > [Note] Now that we have profiles (tiny and generic) we could add an extra folder for them. > > > > I think that having all of the metadata on the same repository can be good for communication. For example, > after a git-pull I might notice that you updated certain kernel configuration values under the "isar" folder that > should be applied to Deby's metadata as well. > > I agree that shared data like reference configs should ideally be stored in one > place. That could be solved by having a single repos for all build systems or by > sticking those artifacts into a separate repo. We already have > https://gitlab.com/cip-project/cip-kernel/cip-kernel-config - maybe add the > configs of the reference boards there? I said "communication" (like in a monorepo) rather than shared data, because each build tool has different methods to store that shared data. In the case of a kernel config, it will probably work fine, but there is always a possibility that we need to add some tuning on the recipe's metadata. > > Another possibility is to use gitlab groups/subgroups in this way: > > > > cip-core/ <-- group > > tiny/ <-- subgroup > > deby <-- git repo > > generic/ <-- subgroup > > isar <-- git repo > > > > I don't have enough permissions to create groups and subgroups under cip-project though (that's the reason > I used the folder approach). > > > > I do. If we agree on the group approach, we need to rename the existing cip-core > repo first, and flatten its folder structure. Then I can create the cip-core > group as well as the tiny/generic subgroups and move the repo. > > Later on, we can factor out the kernel configs. Do you see other shared data? Well, one could be the list of packages for each profile. However, as I mention above it will be hard to share exactly the same files. > > Which way would you prefer? > > I'm leaning towards separate repos. OK, then let's analyze the pros and cons and decide today at the TSC meeting. Thanks, Daniel > > Jan > > > > > Thanks, > > Daniel > > > > [1] https://gitlab.com/cip-project/cip-core/issues/2 > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux