[yocto] Web Hob's design - missing developer workflow?

[Paul Eggleton]

Hi Dave,

On Tuesday 03 July 2012 22:28:12 Stewart, David C wrote:
> Now I want to do something like change the default root password. OK, I
> don't know where that file is located so how do I edit it? (Remember, there
> are no local files to do a find | grep to locate "passwd" anyplace.) So how
> do I change this?
> 
> In fact, if I want to edit any of the static files we provide in YP, I don't
> know how to do this.
>
> Next I want to add my own application, which consists of .c files, .h files
> and a makefile. (Because I am really old school). So I create a .bb file
> for this and then... what? How do I get this collection of files into my
> project in WebHob to build it?
> 
> For that last one, I guess I could treat it as a layer, since I see a way to
> provide an external layer to WebHob. OK, it means I need to create a
> conf/layer.conf file, right? Do I have any clues on how to do this or am I
> on my own?
>
> Oh, and when I tried to make my new layer build, I had a compile error,
> which I just fixed in a .c file. How do I get that file onto the WebHob
> server? Do I need to reload the whole layer?
 
We did discuss this problem earlier, and the conclusion was that people ought 
to be using layers to do their customisation. We can certainly help with that 
process however. I've just talked to Jim and for the prototype he's going to 
be designing in some functionality at the layer level to switch branches and 
fetch the latest version from the remote repository. You can then at least use 
the normal git processes to get updated versions of the metadata, switch 
between master, contrib and stable branches, etc. This is something we can 
reasonably cover for the current design phase.

FYI for updates to the source code itself as opposed to the metadata, it is 
already possible within the build system to have a recipe which always pulls 
the latest version of the source from some git/svn/etc. server (using 
AUTOREV). This mechanism could be used for a live development situation you 
mention above - you would just push your changes to whereever the recipe is 
pointing, and then hit "build" in the web interface, no other interaction 
would be required.

However, some of this will be "learn to walk before we try to run" (to quote 
Richard). I've no doubt we will discover different workflows as people have a 
chance to use it especially for internal collaboration. I think we can 
certainly record though that it would be nice if there was a guided way within 
the interface to create a layer and separately allow modification of common 
configuration files (e.g. /net/network/interfaces) by letting the user edit the 
file and then setting up a bbappend within a layer to apply it.

I'll work with the designers to add these requirements in the form of user 
stories so they can be covered in the next design cycle.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre