* [cip-dev] [RFC] isar-cip-core @ 2019-01-03 18:03 Jan Kiszka 2019-01-04 16:50 ` Jan Kiszka 2019-01-07 0:30 ` Daniel Sangorrin 0 siblings, 2 replies; 15+ messages in thread From: Jan Kiszka @ 2019-01-03 18:03 UTC (permalink / raw) To: cip-dev Hi, happy new year to everyone! New year, new project: I've started isar-cip-core in our incubating area, see https://gitlab.com/cip-playground/isar-cip-core. It's currently only generating an SD card image for the BeagleBone Black, but that can easily be extended. The idea is to model our generic profile CIP Core this way, producing images that contain all supported packages and can then be used for testing, evaluation etc. README is still missing, will write one tomorrow: # wget https://raw.githubusercontent.com/siemens/kas/master/kas-docker # chmod a+x kas-docker # ./kas-docker --isar build kas.yml:board-bbb.yml or # ./kas-docker --isar build kas.yml:board-bbb.yml:opt-rt.yml for the RT variant. Looking forward to feedback! Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* [cip-dev] [RFC] isar-cip-core 2019-01-03 18:03 [cip-dev] [RFC] isar-cip-core Jan Kiszka @ 2019-01-04 16:50 ` Jan Kiszka 2019-01-07 0:30 ` Daniel Sangorrin 1 sibling, 0 replies; 15+ messages in thread From: Jan Kiszka @ 2019-01-04 16:50 UTC (permalink / raw) To: cip-dev On 03.01.19 19:03, Jan Kiszka wrote: > Hi, > > happy new year to everyone! > > New year, new project: I've started isar-cip-core in our incubating area, see > https://gitlab.com/cip-playground/isar-cip-core. > > It's currently only generating an SD card image for the BeagleBone Black, but > that can easily be extended. The idea is to model our generic profile CIP Core > this way, producing images that contain all supported packages and can then be > used for testing, evaluation etc. > > README is still missing, will write one tomorrow: > > # wget https://raw.githubusercontent.com/siemens/kas/master/kas-docker > # chmod a+x kas-docker > # ./kas-docker --isar build kas.yml:board-bbb.yml > > or > > # ./kas-docker --isar build kas.yml:board-bbb.yml:opt-rt.yml > > for the RT variant. > > Looking forward to feedback! > > Jan > README has been added, also a qemu-amd64 target together with a starter script and a target for the SIMATIC IPC227E. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* [cip-dev] [RFC] isar-cip-core 2019-01-03 18:03 [cip-dev] [RFC] isar-cip-core Jan Kiszka 2019-01-04 16:50 ` Jan Kiszka @ 2019-01-07 0:30 ` Daniel Sangorrin 2019-01-07 5:40 ` Jan Kiszka 1 sibling, 1 reply; 15+ messages in thread From: Daniel Sangorrin @ 2019-01-07 0:30 UTC (permalink / raw) To: cip-dev 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. 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). Which way would you prefer? Thanks, Daniel [1] https://gitlab.com/cip-project/cip-core/issues/2 > -----Original Message----- > From: cip-dev-bounces at lists.cip-project.org <cip-dev-bounces@lists.cip-project.org> On Behalf Of Jan Kiszka > Sent: Friday, January 4, 2019 3:03 AM > To: cip-dev <cip-dev@lists.cip-project.org> > Subject: [cip-dev] [RFC] isar-cip-core > > Hi, > > happy new year to everyone! > > New year, new project: I've started isar-cip-core in our incubating area, see > https://gitlab.com/cip-playground/isar-cip-core. > > It's currently only generating an SD card image for the BeagleBone Black, but > that can easily be extended. The idea is to model our generic profile CIP Core > this way, producing images that contain all supported packages and can then be > used for testing, evaluation etc. > > README is still missing, will write one tomorrow: > > # wget https://raw.githubusercontent.com/siemens/kas/master/kas-docker > # chmod a+x kas-docker > # ./kas-docker --isar build kas.yml:board-bbb.yml > > or > > # ./kas-docker --isar build kas.yml:board-bbb.yml:opt-rt.yml > > for the RT variant. > > Looking forward to feedback! > > Jan > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux > _______________________________________________ > cip-dev mailing list > cip-dev at lists.cip-project.org > https://lists.cip-project.org/mailman/listinfo/cip-dev ^ permalink raw reply [flat|nested] 15+ messages in thread
* [cip-dev] [RFC] isar-cip-core 2019-01-07 0:30 ` Daniel Sangorrin @ 2019-01-07 5:40 ` Jan Kiszka 2019-01-07 6:45 ` Daniel Sangorrin 0 siblings, 1 reply; 15+ messages in thread From: Jan Kiszka @ 2019-01-07 5:40 UTC (permalink / raw) To: cip-dev 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? > > 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? > Which way would you prefer? I'm leaning towards separate repos. 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [cip-dev] [RFC] isar-cip-core 2019-01-07 5:40 ` Jan Kiszka @ 2019-01-07 6:45 ` Daniel Sangorrin 2019-01-07 6:59 ` Jan Kiszka 0 siblings, 1 reply; 15+ messages in thread From: Daniel Sangorrin @ 2019-01-07 6:45 UTC (permalink / raw) To: cip-dev > -----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. > > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [cip-dev] [RFC] isar-cip-core 2019-01-07 6:45 ` Daniel Sangorrin @ 2019-01-07 6:59 ` Jan Kiszka 2019-01-07 7:31 ` Daniel Sangorrin 0 siblings, 1 reply; 15+ messages in thread From: Jan Kiszka @ 2019-01-07 6:59 UTC (permalink / raw) To: cip-dev 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? > >>> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [cip-dev] [RFC] isar-cip-core 2019-01-07 6:59 ` Jan Kiszka @ 2019-01-07 7:31 ` Daniel Sangorrin 2019-01-31 5:33 ` daniel.sangorrin at toshiba.co.jp 0 siblings, 1 reply; 15+ messages in thread From: Daniel Sangorrin @ 2019-01-07 7:31 UTC (permalink / raw) To: cip-dev > -----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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [cip-dev] [RFC] isar-cip-core 2019-01-07 7:31 ` Daniel Sangorrin @ 2019-01-31 5:33 ` daniel.sangorrin at toshiba.co.jp 2019-01-31 8:01 ` Agustín Benito Bethencourt 0 siblings, 1 reply; 15+ messages in thread From: daniel.sangorrin at toshiba.co.jp @ 2019-01-31 5:33 UTC (permalink / raw) To: cip-dev Hi Agustin, I need to create the following hierarchy on gitlab: > > > >>> cip-core/ <-- group > > > >>> tiny/ <-- subgroup > > > >>> deby <-- git repo (current cip-core.git) > > > >>> generic/ <-- subgroup > > > >>> isar <-- git repo I don't have enough permissions, could you do that for me and possibly give me permissions for anything under cip-core? Thanks, Daniel > -----Original Message----- > From: cip-dev-bounces at lists.cip-project.org <cip-dev-bounces@lists.cip-project.org> On Behalf Of Daniel > Sangorrin > Sent: Monday, January 7, 2019 4:31 PM > To: 'Jan Kiszka' <jan.kiszka@siemens.com>; '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 > > > > > > > > > -----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 > > _______________________________________________ > cip-dev mailing list > cip-dev at lists.cip-project.org > https://lists.cip-project.org/mailman/listinfo/cip-dev ^ permalink raw reply [flat|nested] 15+ messages in thread
* [cip-dev] [RFC] isar-cip-core 2019-01-31 5:33 ` daniel.sangorrin at toshiba.co.jp @ 2019-01-31 8:01 ` Agustín Benito Bethencourt 2019-01-31 8:52 ` daniel.sangorrin at toshiba.co.jp 2019-02-01 1:35 ` Nobuhiro Iwamatsu 0 siblings, 2 replies; 15+ messages in thread From: Agustín Benito Bethencourt @ 2019-01-31 8:01 UTC (permalink / raw) To: cip-dev Hi jan and Daniel, On Thursday, 31 January 2019 06:33:53 CET daniel.sangorrin at toshiba.co.jp wrote: > Hi Agustin, > > I need to create the following hierarchy on gitlab: > > > > > >>> cip-core/ <-- group > > > > >>> tiny/ <-- subgroup > > > > >>> deby <-- git repo (current cip-core.git) > > > > >>> generic/ <-- subgroup > > > > >>> isar <-- git repo I just created the new subgroup called "cip-core". I moved the project cip-core from the root tree to the new subgroup. I gave both of you owner rights in this new subgroup so you can configure it as you please. Please take a few minutes to go over the configurations so you guys can decide merge request, merge, tickets... strategies. I will be traveling the coming days but feel free to ask me through mail or IRC if you want a second opinion on how to set up the subgroup/projects. I have done it several times with a variety of use cases over the years. We defined a policy in which each Member company has a person as Owner of the whole CIP Group. If you think there should be two people per company to make things more fluid, please propose it. I would be fine with it. I understand sometimes it is not ideal to depend on somebody else for these things. I think it would be useful to agree on basic topics across the different subgroups like some common labels, milestones. boards... so we start to apply some consistency across the different groups on very basic thinks. If you think it might be a good idea I can make a proposal in the coming days. Best Regards -- Agust?n Benito Bethencourt Principal Consultant Codethink Ltd We respect your privacy. See https://www.codethink.co.uk/privacy.html ^ permalink raw reply [flat|nested] 15+ messages in thread
* [cip-dev] [RFC] isar-cip-core 2019-01-31 8:01 ` Agustín Benito Bethencourt @ 2019-01-31 8:52 ` daniel.sangorrin at toshiba.co.jp 2019-02-01 1:35 ` Nobuhiro Iwamatsu 1 sibling, 0 replies; 15+ messages in thread From: daniel.sangorrin at toshiba.co.jp @ 2019-01-31 8:52 UTC (permalink / raw) To: cip-dev Thanks Agustin! > -----Original Message----- > From: Agust?n Benito Bethencourt <agustin.benito@codethink.co.uk> > Sent: Thursday, January 31, 2019 5:02 PM > To: sangorrin daniel(????? ???? ????????) <daniel.sangorrin@toshiba.co.jp>; > jan.kiszka at siemens.com > Cc: cip-dev at lists.cip-project.org > Subject: Re: [cip-dev] [RFC] isar-cip-core > > Hi jan and Daniel, > > On Thursday, 31 January 2019 06:33:53 CET daniel.sangorrin at toshiba.co.jp wrote: > > Hi Agustin, > > > > I need to create the following hierarchy on gitlab: > > > > > > > >>> cip-core/ <-- group > > > > > >>> tiny/ <-- subgroup > > > > > >>> deby <-- git repo (current cip-core.git) > > > > > >>> generic/ <-- subgroup > > > > > >>> isar <-- git repo > > I just created the new subgroup called "cip-core". I moved the project cip-core from the root tree to the new > subgroup. I gave both of you owner rights in this new subgroup so you can configure it as you please. Please take > a few minutes to go over the configurations so you guys can decide merge request, merge, tickets... strategies. > I will be traveling the coming days but feel free to ask me through mail or IRC if you want a second opinion on > how to set up the subgroup/projects. I have done it several times with a variety of use cases over the years. > > We defined a policy in which each Member company has a person as Owner of the whole CIP Group. If you think > there should be two people per company to make things more fluid, please propose it. I would be fine with it. I > understand sometimes it is not ideal to depend on somebody else for these things. > > I think it would be useful to agree on basic topics across the different subgroups like some common labels, > milestones. boards... so we start to apply some consistency across the different groups on very basic thinks. If you > think it might be a good idea I can make a proposal in the coming days. > > Best Regards > > > -- > Agust?n Benito Bethencourt > Principal Consultant > Codethink Ltd > We respect your privacy. See https://www.codethink.co.uk/privacy.html ^ permalink raw reply [flat|nested] 15+ messages in thread
* [cip-dev] [RFC] isar-cip-core 2019-01-31 8:01 ` Agustín Benito Bethencourt 2019-01-31 8:52 ` daniel.sangorrin at toshiba.co.jp @ 2019-02-01 1:35 ` Nobuhiro Iwamatsu 2019-02-01 8:35 ` Agustin Benito Bethencourt 1 sibling, 1 reply; 15+ messages in thread From: Nobuhiro Iwamatsu @ 2019-02-01 1:35 UTC (permalink / raw) To: cip-dev Hi, Agustin. Non-members can not access newly created subgroups. Previously, since cip-core was published, I think that it is a setting problem, but how do you do? Best regards, Nobuhiro 2019?1?31?(?) 17:03 Agust?n Benito Bethencourt <agustin.benito@codethink.co.uk>: > > Hi jan and Daniel, > > On Thursday, 31 January 2019 06:33:53 CET daniel.sangorrin at toshiba.co.jp wrote: > > Hi Agustin, > > > > I need to create the following hierarchy on gitlab: > > > > > > > >>> cip-core/ <-- group > > > > > >>> tiny/ <-- subgroup > > > > > >>> deby <-- git repo (current cip-core.git) > > > > > >>> generic/ <-- subgroup > > > > > >>> isar <-- git repo > > I just created the new subgroup called "cip-core". I moved the project cip-core from the root tree to the new subgroup. I gave both of you owner rights in this new subgroup so you can configure it as you please. Please take a few minutes to go over the configurations so you guys can decide merge request, merge, tickets... strategies. I will be traveling the coming days but feel free to ask me through mail or IRC if you want a second opinion on how to set up the subgroup/projects. I have done it several times with a variety of use cases over the years. > > We defined a policy in which each Member company has a person as Owner of the whole CIP Group. If you think there should be two people per company to make things more fluid, please propose it. I would be fine with it. I understand sometimes it is not ideal to depend on somebody else for these things. > > I think it would be useful to agree on basic topics across the different subgroups like some common labels, milestones. boards... so we start to apply some consistency across the different groups on very basic thinks. If you think it might be a good idea I can make a proposal in the coming days. > > Best Regards > > > -- > Agust?n Benito Bethencourt > Principal Consultant > Codethink Ltd > We respect your privacy. See https://www.codethink.co.uk/privacy.html > _______________________________________________ > cip-dev mailing list > cip-dev at lists.cip-project.org > https://lists.cip-project.org/mailman/listinfo/cip-dev ^ permalink raw reply [flat|nested] 15+ messages in thread
* [cip-dev] [RFC] isar-cip-core 2019-02-01 1:35 ` Nobuhiro Iwamatsu @ 2019-02-01 8:35 ` Agustin Benito Bethencourt 2019-02-04 5:36 ` daniel.sangorrin at toshiba.co.jp 0 siblings, 1 reply; 15+ messages in thread From: Agustin Benito Bethencourt @ 2019-02-01 8:35 UTC (permalink / raw) To: cip-dev Hi, On 1 February 2019 02:35:51 CET, Nobuhiro Iwamatsu <nobuhiro.iwamatsu@miraclelinux.com> wrote: >Hi, Agustin. > >Non-members can not access newly created subgroups. >Previously, since cip-core was published, I think that it is a setting >problem, but how do you do? the new subgroup has inherited every group member. If you cannot access the new subgroup is because you were member of a different subgroup, not the top group. I am traveling and will not have access the next few hours (I rather do this on a laptop). Yo can be added by the new owners. @Daniel, @Jan there is a config option in the subgroup to allow people to request access. Best Regards > >Best regards, > Nobuhiro > >2019?1?31?(?) 17:03 Agust?n Benito Bethencourt ><agustin.benito@codethink.co.uk>: >> >> Hi jan and Daniel, >> >> On Thursday, 31 January 2019 06:33:53 CET >daniel.sangorrin at toshiba.co.jp wrote: >> > Hi Agustin, >> > >> > I need to create the following hierarchy on gitlab: >> > >> > > > > >>> cip-core/ <-- group >> > > > > >>> tiny/ <-- subgroup >> > > > > >>> deby <-- git repo (current cip-core.git) >> > > > > >>> generic/ <-- subgroup >> > > > > >>> isar <-- git repo >> >> I just created the new subgroup called "cip-core". I moved the >project cip-core from the root tree to the new subgroup. I gave both of >you owner rights in this new subgroup so you can configure it as you >please. Please take a few minutes to go over the configurations so you >guys can decide merge request, merge, tickets... strategies. I will be >traveling the coming days but feel free to ask me through mail or IRC >if you want a second opinion on how to set up the subgroup/projects. I >have done it several times with a variety of use cases over the years. >> >> We defined a policy in which each Member company has a person as >Owner of the whole CIP Group. If you think there should be two people >per company to make things more fluid, please propose it. I would be >fine with it. I understand sometimes it is not ideal to depend on >somebody else for these things. >> >> I think it would be useful to agree on basic topics across the >different subgroups like some common labels, milestones. boards... so >we start to apply some consistency across the different groups on very >basic thinks. If you think it might be a good idea I can make a >proposal in the coming days. >> >> Best Regards >> >> >> -- >> Agust?n Benito Bethencourt >> Principal Consultant >> Codethink Ltd >> We respect your privacy. See >https://www.codethink.co.uk/privacy.html >> _______________________________________________ >> cip-dev mailing list >> cip-dev at lists.cip-project.org >> https://lists.cip-project.org/mailman/listinfo/cip-dev -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 15+ messages in thread
* [cip-dev] [RFC] isar-cip-core 2019-02-01 8:35 ` Agustin Benito Bethencourt @ 2019-02-04 5:36 ` daniel.sangorrin at toshiba.co.jp 2019-02-04 9:09 ` Nobuhiro Iwamatsu 0 siblings, 1 reply; 15+ messages in thread From: daniel.sangorrin at toshiba.co.jp @ 2019-02-04 5:36 UTC (permalink / raw) To: cip-dev Iwamatsu-san, I have fixed the permissions. Could you try again and see if it works now? Thanks, Daniel > -----Original Message----- > From: Agustin Benito Bethencourt <agustin.benito@codethink.co.uk> > Sent: Friday, February 1, 2019 5:36 PM > To: Nobuhiro Iwamatsu <nobuhiro.iwamatsu@miraclelinux.com> > Cc: sangorrin daniel(????? ???? ????????) <daniel.sangorrin@toshiba.co.jp>; > jan.kiszka at siemens.com; cip-dev at lists.cip-project.org > Subject: Re: [cip-dev] [RFC] isar-cip-core > > Hi, > > On 1 February 2019 02:35:51 CET, Nobuhiro Iwamatsu <nobuhiro.iwamatsu@miraclelinux.com> wrote: > >Hi, Agustin. > > > >Non-members can not access newly created subgroups. > >Previously, since cip-core was published, I think that it is a setting > >problem, but how do you do? > > the new subgroup has inherited every group member. If you cannot access the new subgroup is because you > were member of a different subgroup, not the top group. > > I am traveling and will not have access the next few hours (I rather do this on a laptop). > > Yo can be added by the new owners. > > @Daniel, @Jan there is a config option in the subgroup to allow people to request access. > > Best Regards > > > > >Best regards, > > Nobuhiro > > > >2019?1?31?(?) 17:03 Agust?n Benito Bethencourt > ><agustin.benito@codethink.co.uk>: > >> > >> Hi jan and Daniel, > >> > >> On Thursday, 31 January 2019 06:33:53 CET > >daniel.sangorrin at toshiba.co.jp wrote: > >> > Hi Agustin, > >> > > >> > I need to create the following hierarchy on gitlab: > >> > > >> > > > > >>> cip-core/ <-- group > >> > > > > >>> tiny/ <-- subgroup > >> > > > > >>> deby <-- git repo (current cip-core.git) > >> > > > > >>> generic/ <-- subgroup > >> > > > > >>> isar <-- git repo > >> > >> I just created the new subgroup called "cip-core". I moved the > >project cip-core from the root tree to the new subgroup. I gave both of > >you owner rights in this new subgroup so you can configure it as you > >please. Please take a few minutes to go over the configurations so you > >guys can decide merge request, merge, tickets... strategies. I will be > >traveling the coming days but feel free to ask me through mail or IRC > >if you want a second opinion on how to set up the subgroup/projects. I > >have done it several times with a variety of use cases over the years. > >> > >> We defined a policy in which each Member company has a person as > >Owner of the whole CIP Group. If you think there should be two people > >per company to make things more fluid, please propose it. I would be > >fine with it. I understand sometimes it is not ideal to depend on > >somebody else for these things. > >> > >> I think it would be useful to agree on basic topics across the > >different subgroups like some common labels, milestones. boards... so > >we start to apply some consistency across the different groups on very > >basic thinks. If you think it might be a good idea I can make a > >proposal in the coming days. > >> > >> Best Regards > >> > >> > >> -- > >> Agust?n Benito Bethencourt > >> Principal Consultant > >> Codethink Ltd > >> We respect your privacy. See > >https://www.codethink.co.uk/privacy.html > >> _______________________________________________ > >> cip-dev mailing list > >> cip-dev at lists.cip-project.org > >> https://lists.cip-project.org/mailman/listinfo/cip-dev > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 15+ messages in thread
* [cip-dev] [RFC] isar-cip-core 2019-02-04 5:36 ` daniel.sangorrin at toshiba.co.jp @ 2019-02-04 9:09 ` Nobuhiro Iwamatsu 2019-02-04 9:25 ` daniel.sangorrin at toshiba.co.jp 0 siblings, 1 reply; 15+ messages in thread From: Nobuhiro Iwamatsu @ 2019-02-04 9:09 UTC (permalink / raw) To: cip-dev Hi, Daniel. I have confirmed that the cip-core group is displayed and I can show to the repository without login. Thanks for your work. Best regards, Nobuhiro 2019?2?4?(?) 14:37 <daniel.sangorrin@toshiba.co.jp>: > > Iwamatsu-san, > > I have fixed the permissions. Could you try again and see if it works now? > > Thanks, > Daniel > > > -----Original Message----- > > From: Agustin Benito Bethencourt <agustin.benito@codethink.co.uk> > > Sent: Friday, February 1, 2019 5:36 PM > > To: Nobuhiro Iwamatsu <nobuhiro.iwamatsu@miraclelinux.com> > > Cc: sangorrin daniel(????? ???? ????????) <daniel.sangorrin@toshiba.co.jp>; > > jan.kiszka at siemens.com; cip-dev at lists.cip-project.org > > Subject: Re: [cip-dev] [RFC] isar-cip-core > > > > Hi, > > > > On 1 February 2019 02:35:51 CET, Nobuhiro Iwamatsu <nobuhiro.iwamatsu@miraclelinux.com> wrote: > > >Hi, Agustin. > > > > > >Non-members can not access newly created subgroups. > > >Previously, since cip-core was published, I think that it is a setting > > >problem, but how do you do? > > > > the new subgroup has inherited every group member. If you cannot access the new subgroup is because you > > were member of a different subgroup, not the top group. > > > > I am traveling and will not have access the next few hours (I rather do this on a laptop). > > > > Yo can be added by the new owners. > > > > @Daniel, @Jan there is a config option in the subgroup to allow people to request access. > > > > Best Regards > > > > > > > >Best regards, > > > Nobuhiro > > > > > >2019?1?31?(?) 17:03 Agust?n Benito Bethencourt > > ><agustin.benito@codethink.co.uk>: > > >> > > >> Hi jan and Daniel, > > >> > > >> On Thursday, 31 January 2019 06:33:53 CET > > >daniel.sangorrin at toshiba.co.jp wrote: > > >> > Hi Agustin, > > >> > > > >> > I need to create the following hierarchy on gitlab: > > >> > > > >> > > > > >>> cip-core/ <-- group > > >> > > > > >>> tiny/ <-- subgroup > > >> > > > > >>> deby <-- git repo (current cip-core.git) > > >> > > > > >>> generic/ <-- subgroup > > >> > > > > >>> isar <-- git repo > > >> > > >> I just created the new subgroup called "cip-core". I moved the > > >project cip-core from the root tree to the new subgroup. I gave both of > > >you owner rights in this new subgroup so you can configure it as you > > >please. Please take a few minutes to go over the configurations so you > > >guys can decide merge request, merge, tickets... strategies. I will be > > >traveling the coming days but feel free to ask me through mail or IRC > > >if you want a second opinion on how to set up the subgroup/projects. I > > >have done it several times with a variety of use cases over the years. > > >> > > >> We defined a policy in which each Member company has a person as > > >Owner of the whole CIP Group. If you think there should be two people > > >per company to make things more fluid, please propose it. I would be > > >fine with it. I understand sometimes it is not ideal to depend on > > >somebody else for these things. > > >> > > >> I think it would be useful to agree on basic topics across the > > >different subgroups like some common labels, milestones. boards... so > > >we start to apply some consistency across the different groups on very > > >basic thinks. If you think it might be a good idea I can make a > > >proposal in the coming days. > > >> > > >> Best Regards > > >> > > >> > > >> -- > > >> Agust?n Benito Bethencourt > > >> Principal Consultant > > >> Codethink Ltd > > >> We respect your privacy. See > > >https://www.codethink.co.uk/privacy.html > > >> _______________________________________________ > > >> cip-dev mailing list > > >> cip-dev at lists.cip-project.org > > >> https://lists.cip-project.org/mailman/listinfo/cip-dev > > > > -- > > Sent from my Android device with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 15+ messages in thread
* [cip-dev] [RFC] isar-cip-core 2019-02-04 9:09 ` Nobuhiro Iwamatsu @ 2019-02-04 9:25 ` daniel.sangorrin at toshiba.co.jp 0 siblings, 0 replies; 15+ messages in thread From: daniel.sangorrin at toshiba.co.jp @ 2019-02-04 9:25 UTC (permalink / raw) To: cip-dev Thanks Iwamatsu-san. Jan: when you move your isar repo to cip-core please add two subgroups for tiny and generic if you want. Otherwise, we can have them on the same level and just mention on the wiki that each belongs to a different profile. Thanks, Daniel > -----Original Message----- > From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu@miraclelinux.com> > Sent: Monday, February 4, 2019 6:09 PM > To: sangorrin daniel(????? ???? ????????) <daniel.sangorrin@toshiba.co.jp> > Cc: agustin.benito at codethink.co.uk; jan.kiszka at siemens.com; cip-dev at lists.cip-project.org > Subject: Re: [cip-dev] [RFC] isar-cip-core > > Hi, Daniel. > > I have confirmed that the cip-core group is displayed and I can show > to the repository without login. > Thanks for your work. > > Best regards, > Nobuhiro > > 2019?2?4?(?) 14:37 <daniel.sangorrin@toshiba.co.jp>: > > > > Iwamatsu-san, > > > > I have fixed the permissions. Could you try again and see if it works now? > > > > Thanks, > > Daniel > > > > > -----Original Message----- > > > From: Agustin Benito Bethencourt <agustin.benito@codethink.co.uk> > > > Sent: Friday, February 1, 2019 5:36 PM > > > To: Nobuhiro Iwamatsu <nobuhiro.iwamatsu@miraclelinux.com> > > > Cc: sangorrin daniel(????? ???? ????????) <daniel.sangorrin@toshiba.co.jp>; > > > jan.kiszka at siemens.com; cip-dev at lists.cip-project.org > > > Subject: Re: [cip-dev] [RFC] isar-cip-core > > > > > > Hi, > > > > > > On 1 February 2019 02:35:51 CET, Nobuhiro Iwamatsu <nobuhiro.iwamatsu@miraclelinux.com> wrote: > > > >Hi, Agustin. > > > > > > > >Non-members can not access newly created subgroups. > > > >Previously, since cip-core was published, I think that it is a setting > > > >problem, but how do you do? > > > > > > the new subgroup has inherited every group member. If you cannot access the new subgroup is because > you > > > were member of a different subgroup, not the top group. > > > > > > I am traveling and will not have access the next few hours (I rather do this on a laptop). > > > > > > Yo can be added by the new owners. > > > > > > @Daniel, @Jan there is a config option in the subgroup to allow people to request access. > > > > > > Best Regards > > > > > > > > > > >Best regards, > > > > Nobuhiro > > > > > > > >2019?1?31?(?) 17:03 Agust?n Benito Bethencourt > > > ><agustin.benito@codethink.co.uk>: > > > >> > > > >> Hi jan and Daniel, > > > >> > > > >> On Thursday, 31 January 2019 06:33:53 CET > > > >daniel.sangorrin at toshiba.co.jp wrote: > > > >> > Hi Agustin, > > > >> > > > > >> > I need to create the following hierarchy on gitlab: > > > >> > > > > >> > > > > >>> cip-core/ <-- group > > > >> > > > > >>> tiny/ <-- subgroup > > > >> > > > > >>> deby <-- git repo (current cip-core.git) > > > >> > > > > >>> generic/ <-- subgroup > > > >> > > > > >>> isar <-- git repo > > > >> > > > >> I just created the new subgroup called "cip-core". I moved the > > > >project cip-core from the root tree to the new subgroup. I gave both of > > > >you owner rights in this new subgroup so you can configure it as you > > > >please. Please take a few minutes to go over the configurations so you > > > >guys can decide merge request, merge, tickets... strategies. I will be > > > >traveling the coming days but feel free to ask me through mail or IRC > > > >if you want a second opinion on how to set up the subgroup/projects. I > > > >have done it several times with a variety of use cases over the years. > > > >> > > > >> We defined a policy in which each Member company has a person as > > > >Owner of the whole CIP Group. If you think there should be two people > > > >per company to make things more fluid, please propose it. I would be > > > >fine with it. I understand sometimes it is not ideal to depend on > > > >somebody else for these things. > > > >> > > > >> I think it would be useful to agree on basic topics across the > > > >different subgroups like some common labels, milestones. boards... so > > > >we start to apply some consistency across the different groups on very > > > >basic thinks. If you think it might be a good idea I can make a > > > >proposal in the coming days. > > > >> > > > >> Best Regards > > > >> > > > >> > > > >> -- > > > >> Agust?n Benito Bethencourt > > > >> Principal Consultant > > > >> Codethink Ltd > > > >> We respect your privacy. See > > > >https://www.codethink.co.uk/privacy.html > > > >> _______________________________________________ > > > >> cip-dev mailing list > > > >> cip-dev at lists.cip-project.org > > > >> https://lists.cip-project.org/mailman/listinfo/cip-dev > > > > > > -- > > > Sent from my Android device with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-02-04 9:25 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-01-03 18:03 [cip-dev] [RFC] isar-cip-core Jan Kiszka 2019-01-04 16:50 ` Jan Kiszka 2019-01-07 0:30 ` Daniel Sangorrin 2019-01-07 5:40 ` Jan Kiszka 2019-01-07 6:45 ` Daniel Sangorrin 2019-01-07 6:59 ` Jan Kiszka 2019-01-07 7:31 ` Daniel Sangorrin 2019-01-31 5:33 ` daniel.sangorrin at toshiba.co.jp 2019-01-31 8:01 ` Agustín Benito Bethencourt 2019-01-31 8:52 ` daniel.sangorrin at toshiba.co.jp 2019-02-01 1:35 ` Nobuhiro Iwamatsu 2019-02-01 8:35 ` Agustin Benito Bethencourt 2019-02-04 5:36 ` daniel.sangorrin at toshiba.co.jp 2019-02-04 9:09 ` Nobuhiro Iwamatsu 2019-02-04 9:25 ` daniel.sangorrin at toshiba.co.jp
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.