[yocto] Some questions about the webhob design
Paul Eggleton
paul.eggleton at linux.intel.com
Fri Jul 6 04:22:37 PDT 2012
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
More information about the yocto
mailing list