[OE-core] [PATCH] Add support for remote layering.

[Jeremy Puhlman]

> I agree the patch has a use in its own right, standalone. I am however
> asking us all to take a step back and consider the big picture which is
> what I need do with a lot of what we're doing.
> 
> My point is that whilst in isolation its ok, I don't think that approach
> can scale to fulfil all the varying needs of our users. If it can't, we
> need to look at what can, and then how we could include equivalent
> functionality.

Okay.

> Even with the code we're discussing, you need an external tool to create
> the list and to update it at appropriate points from upstream so you
> really might as well have that code actually do the fetch as well
> (calling bitbake's fetchers)?

Well in its current state, you don't need one, but it makes it a lot
easier. OTOH all this discussion more or less centers around BBLAYERS
which is already easy to use.

> I'm much more worried about the workflow and its implications than I am
> about the actual code.

Okay. More ore less this really only expands the options for workflow.

> I think layers are a bit different to a lot of the source code we
> currently fetch. We might want to push things back, transfer commits
> between layers and perform a number of other operations.

Unless we are writing a new set of fetchers(internal or otherwise), the
limitation is the fetchers, since they don't do this.

> These
> operations all require "state" type data that currently we can't store
> in a SRC_URI. I'm not even sure we want to store it there.

Wouldn't you have the same issue with a git repo tracking recipe?

> 
> There has been discussion about this in person at Collab/ELC and on
> the mailing lists/wikis but we probably need to do better at
> communicating this I guess :/

Yes. Been following a long, trying to contribute where it made sense.
OTOH, in the end, if it is insufficient for our needs we can't use it.
> The whole point of Yocto is to collaborate. I'm pleased to have your
> input in the form of the patches and I really do appreciate that.
> 
> This doesn't however guarantee we take them "as is" since we've also
> consulted with a number of other people about what their needs are and
> your solution whilst evidently perfect for you doesn't meet all the
> criteria we established during the planning process. 

I never suggested that anything be taken as is. In the irc discussions
with Paul, we talked about the bits that we wanted to change.

> We're trying to
> write some tools that should work for everyone. It may require some
> changes in process for some people, hopefully these will be logical and
> improve the user experience and understanding.

Understood, otherwise I wouldn't be having this e-mail exchange with you
at all.

> There are a variety of ways I think we could even directly make your use
> case work (such as bitbake automatically calling the external update
> tool if some environment variable is set). 

Okay.


> Collaboration means there are
> more than just your requirements that need to be worked into this at
> this point.

Nor have I suggested that you guys were.

> What's the opinion of fetch2 at this point? I'm hoping we can rely on
> that for all future development work at this point.

>From the I am just using fetchers in a more or less rudimentary manner,
it feels more or less the same(which kind a was the point). I have not
really used any of the additional stuff that has been added in, but more
powerful and functionally rich code is always a positive thing.

Also I am currently supporting fetch with our older product so when I
wrote the patch, making it work with fetch seemed a good idea.

> 
> I'm probably confusing this with the first version you sent out I guess,
> sorry.
> 

That was my point, there was only one. Really doesn't matter.

>> We can move the setting of that stuff to the init of the fetchers, and
>> that wouldn't be a big deal.
> 
> I understand that. You're not thinking about what I'm suggesting ;-)
> 

I caught what you were striving for there.

-- 
Jeremy Puhlman
Montavista Sofware, LLC.