[cip-dev] [RFC] isar-cip-core

[daniel.sangorrin@toshiba.co.jp (Daniel Sangorrin)]

> -----Original Message-----
> From: Jan Kiszka <jan.kiszka@siemens.com>
> Sent: Monday, January 7, 2019 3:59 PM
> To: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>; 'cip-dev' <cip-dev@lists.cip-project.org>
> Subject: Re: [cip-dev] [RFC] isar-cip-core
> 
> 
> 
> > -----Original Message-----
> > From: Jan Kiszka <jan.kiszka@siemens.com>
> > Sent: Monday, January 7, 2019 3:59 PM
> > To: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>; 'cip-dev' <cip-dev@lists.cip-project.org>
> > Subject: Re: [cip-dev] [RFC] isar-cip-core
> >
> > On 07.01.19 07:45, Daniel Sangorrin wrote:
> > >> -----Original Message-----
> > >> From: Jan Kiszka <jan.kiszka@siemens.com>
> > >> Sent: Monday, January 7, 2019 2:41 PM
> > >> To: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>; 'cip-dev' <cip-dev@lists.cip-project.org>
> > >> 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.
> >
> > When it comes to pure communication, the mailing list is a better place. We
> > could route all cip-core patches through it (rather than splitting up the work
> > in isolated MRs on gitlab).
> >
> > >
> > >>> 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.
> >
> > Yes, sharing the package list 1:1 will only work if the tiny profile follows the
> > standard Debian binary packaging structure - does/will it?

Not necessarily.
For example, Deby follows the Open Embedded structure as far as I know.

Thanks,
Daniel

> >
> > >
> > >>> 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.
> >
> > Fine with me.
> >
> > Jan
> >
> > --
> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> > Corporate Competence Center Embedded Linux