Re: Some questions about the webhob design

[Paul Eggleton <paul.eggleton@linux.intel.com>]

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