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

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

[Jan Kiszka]

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] [RFC] isar-cip-core

[Jan Kiszka]

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

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

[Daniel Sangorrin]

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

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

[Jan Kiszka]

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

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

[Daniel Sangorrin]

> -----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

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

[Jan Kiszka]

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

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

[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

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

[daniel.sangorrin at toshiba.co.jp]

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

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

[Agustín Benito Bethencourt]

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] [RFC] isar-cip-core

[daniel.sangorrin at toshiba.co.jp]

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

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

[Nobuhiro Iwamatsu]

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

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

[Agustin Benito Bethencourt]

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.

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

[daniel.sangorrin at 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.

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

[Nobuhiro Iwamatsu]

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.

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

[daniel.sangorrin at toshiba.co.jp]

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.