Some questions about the webhob design

Some questions about the webhob design

[Xu, Dongxiao]

Hi Paul and Jim,

Today Jessica and PRC team had a discussion of the webhob tasks listed in the wiki page, and about the "Group" and "Project" concept, we still have some questions.

Say user A and user B are privileged users, who have the right to customize images, while user C is normal user (Say a TME) and only "building image" is allowed.

1) If user A customized an image with certain configurations, and he told user C that the environment is ready, and user C can build his demo image there. However, before user C starts to build, user B changed some configurations, making the final output not the expected version.

2) Another issue may be how to avoid global project changes happened together? For example user A and user B change the setting in the same time?

3) If user A changes the global project setting, what's the impact to the user B who already kicked off a build based on the original setting?

We are really appreciate if you can help to clarify these questions for us.

Thanks,
Dongxiao

Re: Some questions about the webhob design

[Jim Kosem]

[-- Attachment #1: Type: text/plain, Size: 2217 bytes --]

Hi,


   1. Paul and I had talked about the last one doing something wins. So if
   I am selecting Package Groups or Recipes and someone selects another
   recipe, this would be updated in my interface as well with an indication
   that it has been updated. However, the final build would reflect both
   selections.
   2. Again, for now, and this could be changed in the future when we have
   users and real use cases, the last person to change something has their
   change.
   3. User A would have his settings impact User B's build.

Again, our thinking is that this is the first version of WebHob and there
is still work to be done on permissions and groups. However, we need to at
this stage keep things simple and then once in testing, we can see how
people may or may not work over one another.

--
Jim Kosem

Skype: jkosem
Gtalk: jim@halfman.com
Mobile: +44 7757 559081

Note: I read and reply to email only a couple of times a day. If you need
something quicker, please use Skype, GTalk or if its urgent call my mobile.



On 3 July 2012 13:10, Xu, Dongxiao <dongxiao.xu@intel.com> wrote:

> Hi Paul and Jim,
>
> Today Jessica and PRC team had a discussion of the webhob tasks listed in
> the wiki page, and about the "Group" and "Project" concept, we still have
> some questions.
>
> Say user A and user B are privileged users, who have the right to
> customize images, while user C is normal user (Say a TME) and only
> "building image" is allowed.
>
> 1) If user A customized an image with certain configurations, and he told
> user C that the environment is ready, and user C can build his demo image
> there. However, before user C starts to build, user B changed some
> configurations, making the final output not the expected version.
>
> 2) Another issue may be how to avoid global project changes happened
> together? For example user A and user B change the setting in the same time?
>
> 3) If user A changes the global project setting, what's the impact to the
> user B who already kicked off a build based on the original setting?
>
> We are really appreciate if you can help to clarify these questions for us.
>
> Thanks,
> Dongxiao
>

[-- Attachment #2: Type: text/html, Size: 2686 bytes --]

Re: Some questions about the webhob design

[Paul Eggleton]

On Tuesday 03 July 2012 12:10:57 Xu, Dongxiao wrote:
> Today Jessica and PRC team had a discussion of the webhob tasks listed in
> the wiki page, and about the "Group" and "Project" concept, we still have
> some questions.

Let's be clear though from the below, we're talking about projects only.
 
> Say user A and user B are privileged users, who have the right to customize
> images, while user C is normal user (Say a TME) and only "building image"
> is allowed.
> 
> 1) If user A customized an image with certain configurations, and he told
> user C that the environment is ready, and user C can build his demo image
> there. However, before user C starts to build, user B changed some
> configurations, making the final output not the expected version.

So firstly, in the design, any change to a project made by a user that occurs 
while another user is also configuring a build on that same project should be 
reflected in real-time in the other user's interface, and will be accompanied 
by a notification that a change has been made.

When more than one user is working on a project, it is expected that they 
would all be working towards the same goal. Creating separate projects for 
separate work efforts that may have different needs is intended to be easy. If a 
user does want to do some experimenting on a project in isolation, the design 
provides for the ability to duplicate the project which can then be modified 
privately without affecting the original project.

It's also a similar situation to working with any other shared resource such 
as a source code repository or a shared document - some discipline is 
required, and there's a limit to how much the tool can enforce in terms of 
people not messing up other people's work (other than providing a permissions 
framework, of course).

> 2) Another issue may be how to avoid global project changes happened
> together? For example user A and user B change the setting in the same
> time?

At the implementation level, with the usual database-level locking there must 
be a "winner" and a "loser" in this situation. The "winner" in our case should 
be whoever made the change last. As above there will be notifications shown to 
both users.
 
> 3) If user A changes the global project setting, what's the impact to the
> user B who already kicked off a build based on the original setting?

Once the build has started it should be isolated from the configuration within 
the interface, i.e. any subsequent changes should not affect it. Internally in 
the implementation I would recommend taking a lock on the project settings as 
soon as the user requests the build to start, which shortly afterwards can be 
released once the build has actually started - but this is not something that 
should be visible at a user level, except as a minor delay. In case user B 
goes back in to view the settings that are now different to what is being used 
for the build, the system should be able to fairly easily show a note within 
the configuration screen that the settings shown have been changed since the 
currently executing build was started.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Some questions about the webhob design

[Zhang, Jessica]

Please see my comments/questions below...

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Paul Eggleton
Sent: Thursday, July 05, 2012 3:01 AM
To: yocto@yoctoproject.org
Subject: Re: [yocto] Some questions about the webhob design

On Tuesday 03 July 2012 12:10:57 Xu, Dongxiao wrote:
> Today Jessica and PRC team had a discussion of the webhob tasks listed
> in the wiki page, and about the "Group" and "Project" concept, we
> still have some questions.

Let's be clear though from the below, we're talking about projects only.
 [JZ] Yeah, let's focus on project's configuration for this thread.

> Say user A and user B are privileged users, who have the right to
> customize images, while user C is normal user (Say a TME) and only "building image"
> is allowed.
>
> 1) If user A customized an image with certain configurations, and he
> told user C that the environment is ready, and user C can build his
> demo image there. However, before user C starts to build, user B
> changed some configurations, making the final output not the expected version.

So firstly, in the design, any change to a project made by a user that occurs while another user is also configuring a build on that same project should be reflected in real-time in the other user's interface, and will be accompanied by a notification that a change has been made.


<JZ> Can we clarify some definition here, when we talk about project build configuration, are they the same as in current hob's saved template? So, if a user configure a build for the project and want to preserve the changes, he/she will achieve so through save template? And we only allow one build configuration per project? </JZ>


When more than one user is working on a project, it is expected that they would all be working towards the same goal. Creating separate projects for separate work efforts that may have different needs is intended to be easy.

<JZ> Agreed overall, but let's look at some particular cases to flesh out the rule further.  Say we have a project webhobtesting. For user A he set the package system as RPM, where user B wants to use deb.  So should we 1) create 2 projects webhobtesting-rpm and webhobtesting-ipk; 2)one webhobtesting project, but depends on who made the modification last, the package system will be set as the last user's preference? This will be what Dongxiao's talking about in the original question.  After user A configure as RPM and told TME to open the project and run the build.  In the meantime, user B switch it to deb.  So the TME's build output will not match what he'd expected that user A has set it to.  Also, we can't expect that user A is also login to receive the notification that his configuration has been changed; 3) we allow multiple configuration files against same project, which requires a project level configuration management mechanism. </JZ>

 If a user does want to do some experimenting on a project in isolation, the design provides for the ability to duplicate the project which can then be modified privately without affecting the original project.

<JZ> So this means we will allow each individual user to create his/her own sandbox which I agree.  Then we'll need to design the mechanism to distinguish the real project build configuration and user private ones. And the implication of that </JZ>

It's also a similar situation to working with any other shared resource such as a source code repository or a shared document - some discipline is required, and there's a limit to how much the tool can enforce in terms of people not messing up other people's work (other than providing a permissions framework, of course).

> 2) Another issue may be how to avoid global project changes happened
> together? For example user A and user B change the setting in the same
> time?

At the implementation level, with the usual database-level locking there must be a "winner" and a "loser" in this situation. The "winner" in our case should be whoever made the change last. As above there will be notifications shown to both users.

<JZ> But if we are really talking about concurrency here, isn't committing the change will be protected by a critical section and whoever got the lock wins?</JZ>

> 3) If user A changes the global project setting, what's the impact to
> the user B who already kicked off a build based on the original setting?

Once the build has started it should be isolated from the configuration within the interface, i.e. any subsequent changes should not affect it. Internally in the implementation I would recommend taking a lock on the project settings as soon as the user requests the build to start, which shortly afterwards can be released once the build has actually started - but this is not something that should be visible at a user level, except as a minor delay. In case user B goes back in to view the settings that are now different to what is being used for the build, the system should be able to fairly easily show a note within the configuration screen that the settings shown have been changed since the currently executing build was started.

<JZ> Agreed </JZ>
Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: Some questions about the webhob design

[Paul Eggleton]

On Thursday 05 July 2012 21:29:35 Zhang, Jessica wrote:
> So firstly, in the design, any change to a project made by a user that
> occurs while another user is also configuring a build on that same project
> should be reflected in real-time in the other user's interface, and will be
> accompanied by a notification that a change has been made.
> 
> <JZ> Can we clarify some definition here, when we talk about project build
> configuration, are they the same as in current hob's saved template? So, if
> a user configure a build for the project and want to preserve the changes,
> he/she will achieve so through save template? And we only allow one build
> configuration per project? </JZ>

Templates are for starting new projects from scratch, as in the current hob 
they are for starting new builds from scratch. Changes to a project's 
configuration are saved to the project itself immediately - there's no need to 
hit "save" anywhere; that's why it has to be reflected in real-time for other 
logged-in users. If you close the browser in the middle of configuring the 
project then some time later re-log in, the project's configuration will be 
exactly how you left it (assuming nobody else has changed it in the mean 
time).

> When more than one user is working on a project, it is expected that they
> would all be working towards the same goal. Creating separate projects for
> separate work efforts that may have different needs is intended to be easy.
> 
> <JZ> Agreed overall, but let's look at some particular cases to flesh out
> the rule further.  Say we have a project webhobtesting. For user A he set
> the package system as RPM, where user B wants to use deb.  So should we 1)
> create 2 projects webhobtesting-rpm and webhobtesting-ipk; 2)one
> webhobtesting project, but depends on who made the modification last, the
> package system will be set as the last user's preference? This will be what
> Dongxiao's talking about in the original question.  After user A configure
> as RPM and told TME to open the project and run the build.  In the
> meantime, user B switch it to deb.  So the TME's build output will not
> match what he'd expected that user A has set it to.  Also, we can't expect
> that user A is also login to receive the notification that his
> configuration has been changed; 3) we allow multiple configuration files
> against same project, which requires a project level configuration
> management mechanism. </JZ>

So leaving aside that this specific example is completely artificial, user B has 
failed to exercise discipline in editing a shared resource which in this case 
appears to have some business value. If user B has access rights to modify 
this shared project, then they are presumably trusted to know when it's 
appropriate to make changes to that project. It's the same situation as a 
"rogue" developer with access to commit to a source code repository making an 
ill-considered commit to the release branch the day before a release build.

I don't think we should move to a #3 state at this stage because not only does 
it add an extra level of configuration selections, it also means we will likely 
have to provide the ability to compare and merge separate configurations which 
is yet more complex functionality both to implement and to present to the 
user.

>  If a user does want to do some experimenting on a project in isolation, the
> design provides for the ability to duplicate the project which can then be
> modified privately without affecting the original project.
> 
> <JZ> So this means we will allow each individual user to create his/her own
> sandbox which I agree.  Then we'll need to design the mechanism to
> distinguish the real project build configuration and user private ones. And
> the implication of that </JZ>

The design already covers this although it is not explicit - a "user private" 
project is simply a project where only one user has permission to view/edit 
it; so we shouldn't need any extra functionality here.

> > 2) Another issue may be how to avoid global project changes happened
> > together? For example user A and user B change the setting in the same
> > time?
> 
> At the implementation level, with the usual database-level locking there
> must be a "winner" and a "loser" in this situation. The "winner" in our
> case should be whoever made the change last. As above there will be
> notifications shown to both users.
> 
> <JZ> But if we are really talking about concurrency here, isn't committing
> the change will be protected by a critical section and whoever got the lock
> wins?</JZ>

That's what I mean, yes.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Some questions about the webhob design

[Stewart, David C]

>From: yocto-bounces@yoctoproject.org [mailto:yocto-
>bounces@yoctoproject.org] On Behalf Of Paul Eggleton
>Sent: Thursday, July 05, 2012 3:20 PM
>

>Templates are for starting new projects from scratch, as in the current hob
>they are for starting new builds from scratch. Changes to a project's
>configuration are saved to the project itself immediately - there's no need to
>hit "save" anywhere; that's why it has to be reflected in real-time for other
>logged-in users. If you close the browser in the middle of configuring the
>project then some time later re-log in, the project's configuration will be
>exactly how you left it (assuming nobody else has changed it in the mean
>time).

Guys - I'm really struggling with this overall concept of concurrency.

It implies that if Paul and I are sharing the same project and I make a change to a .bb file to experiment with something (assuming we have the ability to do that, refer to my last email) and my change breaks my build, it will break everyone else's build as well.  But the beauty thing is that it breaks it silently, because the configuration silently changed for everyone on the project.

If you are saying that it won't happen because people won't share a project under active development, then I don't understand the value of sharing a project. Is it to share the package repo? The images? There are all kinds of ways of doing that.

I think someone needs to sit down and write out the *complete* user stories for how people use the system. 

Re: Some questions about the webhob design

[Paul Eggleton]

On Thursday 05 July 2012 23:00:17 Stewart, David C wrote:
> Guys - I'm really struggling with this overall concept of concurrency.
> 
> It implies that if Paul and I are sharing the same project and I make a
> change to a .bb file to experiment with something (assuming we have the
> ability to do that, refer to my last email) and my change breaks my build,
> it will break everyone else's build as well.  But the beauty thing is that
> it breaks it silently, because the configuration silently changed for
> everyone on the project.

The key word there I think is "experiment". Is it reasonable to expect to 
handle people making experimental changes to something that others are relying 
upon? It seems to me that whether experimental changes are likely and whether 
or not it will seriously impact other users depends on what development stage 
the particular project is at.

We're providing an avenue for the user to make a copy of the project that they 
can play with. We also aren't completely managing all of the metadata and 
source code through this tool - that's something git and other version control 
tools do pretty well. So it's perfectly possible to have the shared project 
operating from master or some release branch of a layer, and my copy of that 
project which pulls the layer from my personal branch of the layer; there I 
can make whatever changes to the metadata I like and when they're ready I can 
use my normal development processes to get that change from my branch into the 
branch being used for the shared project.

> If you are saying that it won't happen because people won't share a project
> under active development, then I don't understand the value of sharing a
> project. Is it to share the package repo? The images? There are all kinds
> of ways of doing that.

I'm expecting people will share a project under active development; they just 
might not put changes into it until they've tested them elsewhere (i.e. their 
own copy of the project) first.

The project will share the built packages and shared state cache (assuming 
that isn't shared at a higher level) between users of the project, but the 
main point is providing an avenue for users to collaborate where it makes 
sense on the *configuration* and not encouraging the opposite, which is people 
off building their separate OS images in their own sandboxes. Ultimately if 
you're working on an OS for a product you have to eventually arrive at the 
same configuration (and by extension, the same metadata and therefore the same 
source code).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Some questions about the webhob design

[Stewart, David C]

> From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
> Sent: Friday, July 06, 2012 4:23 AM
> To: Stewart, David C
> 
> On Thursday 05 July 2012 23:00:17 Stewart, David C wrote:
> > Guys - I'm really struggling with this overall concept of concurrency.
> >
> > It implies that if Paul and I are sharing the same project and I make
> > a change to a .bb file to experiment with something (assuming we have
> > the ability to do that, refer to my last email) and my change breaks
> > my build, it will break everyone else's build as well.  But the beauty
> > thing is that it breaks it silently, because the configuration
> > silently changed for everyone on the project.
> 
> The key word there I think is "experiment". Is it reasonable to expect to
> handle people making experimental changes to something that others are
> relying upon? It seems to me that whether experimental changes are likely
> and whether or not it will seriously impact other users depends on what
> development stage the particular project is at.

Whether it is reasonable or not, if it's possible for people to shoot themselves in the foot, they will.  Even with safety guards on a circular saw, I have seen people routinely disable them, so there you go.

How about a strongly visible warning on the Projects page that simultaneous user changes will affect all users of the project's files? How about an asynchronous notification to users on the main screen that some files have changed since their last build (and maybe list them).

Again, writing a user story is what I'm looking for. I would do it myself, but I'm still struggling. :-)

Re: Some questions about the webhob design

[Paul Eggleton]

On Friday 06 July 2012 17:13:45 Stewart, David C wrote:
> > From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
> > Sent: Friday, July 06, 2012 4:23 AM
> > To: Stewart, David C
> > 
> > On Thursday 05 July 2012 23:00:17 Stewart, David C wrote:
> > > Guys - I'm really struggling with this overall concept of concurrency.
> > > 
> > > It implies that if Paul and I are sharing the same project and I make
> > > a change to a .bb file to experiment with something (assuming we have
> > > the ability to do that, refer to my last email) and my change breaks
> > > my build, it will break everyone else's build as well.  But the beauty
> > > thing is that it breaks it silently, because the configuration
> > > silently changed for everyone on the project.
> > 
> > The key word there I think is "experiment". Is it reasonable to expect to
> > handle people making experimental changes to something that others are
> > relying upon? It seems to me that whether experimental changes are likely
> > and whether or not it will seriously impact other users depends on what
> > development stage the particular project is at.
> 
> Whether it is reasonable or not, if it's possible for people to shoot
> themselves in the foot, they will.  Even with safety guards on a circular
> saw, I have seen people routinely disable them, so there you go.

Right, and the logical extension from this is that no matter what safeguards 
we put in, there will be users that find a way shoot themselves in the foot. Of 
course we should try to make it harder to do the wrong thing, but there's a 
limit to what we can do. Despite this however I'm still convinced it's 
important to offer the ability for people to work on the same thing.

> How about a strongly visible warning on the Projects page that simultaneous
> user changes will affect all users of the project's files? How about an
> asynchronous notification to users on the main screen that some files have
> changed since their last build (and maybe list them).

I'm not opposed to a warning, but the thing is the scenario presented earlier 
wasn't strictly speaking a case of simultaneous user changes (which I think we 
have pretty well covered in the design in terms of showing real-time warnings 
to go together with real-time changes to the project) - in the scenario one 
user set up the project, and some time later another user attempted to use 
that project, and in the mean time someone broke it while neither of the other 
two users were logged in. A warning to help in that case could only be along 
the lines of "This project is shared with other users, so please take care 
when making changes."

> Again, writing a user story is what I'm looking for. I would do it myself,
> but I'm still struggling. :-)

I spoke to Jim about this and he's going to put something together, but it's 
likely that if what you're after is a full explanation of the workflow that 
it's a significant exercise.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Some questions about the webhob design

[Xu, Dongxiao]

> -----Original Message-----
> From: yocto-bounces@yoctoproject.org
> [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Paul Eggleton
> Sent: Saturday, July 07, 2012 1:30 AM
> To: Stewart, David C
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Some questions about the webhob design
> 
> On Friday 06 July 2012 17:13:45 Stewart, David C wrote:
> > > From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
> > > Sent: Friday, July 06, 2012 4:23 AM
> > > To: Stewart, David C
> > >
> > > On Thursday 05 July 2012 23:00:17 Stewart, David C wrote:
> > > > Guys - I'm really struggling with this overall concept of concurrency.
> > > >
> > > > It implies that if Paul and I are sharing the same project and I
> > > > make a change to a .bb file to experiment with something (assuming
> > > > we have the ability to do that, refer to my last email) and my
> > > > change breaks my build, it will break everyone else's build as
> > > > well.  But the beauty thing is that it breaks it silently, because
> > > > the configuration silently changed for everyone on the project.
> > >
> > > The key word there I think is "experiment". Is it reasonable to
> > > expect to handle people making experimental changes to something
> > > that others are relying upon? It seems to me that whether
> > > experimental changes are likely and whether or not it will seriously
> > > impact other users depends on what development stage the particular
> project is at.
> >
> > Whether it is reasonable or not, if it's possible for people to shoot
> > themselves in the foot, they will.  Even with safety guards on a
> > circular saw, I have seen people routinely disable them, so there you go.
> 
> Right, and the logical extension from this is that no matter what safeguards we
> put in, there will be users that find a way shoot themselves in the foot. Of
> course we should try to make it harder to do the wrong thing, but there's a
> limit to what we can do. Despite this however I'm still convinced it's important
> to offer the ability for people to work on the same thing.
> 
> > How about a strongly visible warning on the Projects page that
> > simultaneous user changes will affect all users of the project's
> > files? How about an asynchronous notification to users on the main
> > screen that some files have changed since their last build (and maybe list
> them).
> 
> I'm not opposed to a warning, but the thing is the scenario presented earlier
> wasn't strictly speaking a case of simultaneous user changes (which I think we
> have pretty well covered in the design in terms of showing real-time warnings
> to go together with real-time changes to the project) - in the scenario one user
> set up the project, and some time later another user attempted to use that
> project, and in the mean time someone broke it while neither of the other two
> users were logged in. A warning to help in that case could only be along the
> lines of "This project is shared with other users, so please take care when
> making changes."

Hi Paul,

Today Jessica and PRC team spend some time thinking about the development model that how people co-work within the webhob project.

Say an architect (his user id is "arch_a") creates a project with certain configurations and customizations, and names it as "Project_FRI2", and he invites "arch_b" also as the architect. Besides that, the project recruits "dev_a", "dev_b", and "dev_c" as developers, and "builer_a", "builder_b", and "builder_c" as normal build service users.

According to our discussion, we have some proposal on the permission management, and need your comments here.

1) Only "arch_a" and "arch_b" are allowed to change project settings (including configurations, recipes, packages, etc).
2) "dev_a", "dev_b", and "dev_c" have the permission to fork this project. If they want to made any change to "Project_FRI2", they firstly need to tune their code/layers under their forked project, and then contribute back to the main "Project_FRI2" (This is something like the git branches and pull request we use in Yocto project development ). They are not allowed to modify project settings directly in "Project_FRI2".
3) "builder_a", "builder_b", and "builder_c" are only allowed to log into the Project_FRI2 project and schedule their build on it, or download images. 

Of course there should be other roles, like program manager, etc.
The overall idea is only very small set of the users could change the project setting. This sort of permission management can help to reduce the rate of changing project setting at the same time, since we no longer support developers to change settings in the main project. The developers need to follow the way of "fork project--> development --> contribute back to main project".

What's your thought on this?

Thanks,
Dongxiao

> 
> > Again, writing a user story is what I'm looking for. I would do it
> > myself, but I'm still struggling. :-)
> 
> I spoke to Jim about this and he's going to put something together, but it's
> likely that if what you're after is a full explanation of the workflow that it's a
> significant exercise.
> 
> Cheers,
> Paul
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Some questions about the webhob design

[Paul Eggleton]

On Tuesday 10 July 2012 06:58:02 Xu, Dongxiao wrote:
> Say an architect (his user id is "arch_a") creates a project with certain
> configurations and customizations, and names it as "Project_FRI2", and he
> invites "arch_b" also as the architect. Besides that, the project recruits
> "dev_a", "dev_b", and "dev_c" as developers, and "builer_a", "builder_b",
> and "builder_c" as normal build service users.
> 
> According to our discussion, we have some proposal on the permission
> management, and need your comments here.
> 
> 1) Only "arch_a" and "arch_b" are allowed to change project settings
> (including configurations, recipes, packages, etc). 2) "dev_a", "dev_b",
> and "dev_c" have the permission to fork this project. If they want to made
> any change to "Project_FRI2", they firstly need to tune their code/layers
> under their forked project, and then contribute back to the main
> "Project_FRI2" (This is something like the git branches and pull request we
> use in Yocto project development ). They are not allowed to modify project
> settings directly in "Project_FRI2". 3) "builder_a", "builder_b", and
> "builder_c" are only allowed to log into the Project_FRI2 project and
> schedule their build on it, or download images.
> 
> Of course there should be other roles, like program manager, etc.
> The overall idea is only very small set of the users could change the
> project setting. This sort of permission management can help to reduce the
> rate of changing project setting at the same time, since we no longer
> support developers to change settings in the main project. The developers
> need to follow the way of "fork project--> development --> contribute back
> to main project".
> 
> What's your thought on this?

This sounds reasonable. The "roles" would not be fixed in the system, but if 
you expect to have multiple people in each role then you could set up groups 
to represent their permissions.

The only issue is we do not offer a merge function, and if you start calling it 
"fork" people may expect to have a corresponding "merge". I expect we can get 
away with not having this feature in the first version but if "forking" becomes 
part of the recommended workflow then we may need to look at adding it in the 
future.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre