> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Paul Eggleton > Sent: Saturday, July 07, 2012 1:30 AM > To: Stewart, David C > Cc: [email protected] > 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:[email protected]] > > > 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 > [email protected] > https://lists.yoctoproject.org/listinfo/yocto _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
