Re: Some questions about the webhob design

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

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