[yocto] Personal git repositories

Elizabeth Flanagan elizabeth.flanagan at intel.com
Wed Apr 27 11:29:12 PDT 2011


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



More information about the yocto mailing list