On 04/27/2011 11:14 AM, Joshua Lock wrote:

On Wed, 2011-04-27 at 10:20 -0700, Elizabeth Flanagan wrote:

A few notes, since I talked with Darren about this earlier.

As one of the people in charge of maintaining the git repo, I would like to avoid having, as Darren suggested, a whole
bunch of -contrib repos. However, maybe I'm missing something here, as I think basic git solves this issue:

I don't agree. I have a few sparse layers and some other code that I am
not sharing because they need repositories *somewhere*.

Different use case from what I'm seeing as the general concern, however, I would say that if someone has code that doesn't belong in oe-core but it's standalone and useful to the project, then you would put in a request to have a new repo added. And maybe that's a good argument for new infrastructure if the current process doesn't scale well (which I don't have data that would come to any conclusion like that).

Having said that some of these recipes may be useful to others yet
definitely don't belong in oe-core. What do I do with them? The
mechanism Darren describes seems like it would work for my use case.

Ask me to create a repo. If I was getting a flood of repo creation requests or there was a use case that was compelling, I'd be on board with this in a heartbeat, but to me, it just seems like it's better served by people understanding the process better.

The current process is to send me an email (ccing RP), saying what repo you want, why you need it and then we go from there and create it, if it makes sense. I think I'm specifically worried less about your use case (I get *maybe* a repo request a month) than I am about people justifying an infrastructure change in order to have a whole bunch of contrib repos. That is better served by sparse fetches of needed branches from poky-contrib.


---------------
Elizabeth Flanagan
Yocto Project
Release Engineer