All of lore.kernel.org
 help / color / mirror / Atom feed
From: Elizabeth Flanagan <elizabeth.flanagan@intel.com>
To: yocto@yoctoproject.org
Subject: Re: Personal git repositories
Date: Wed, 27 Apr 2011 11:29:12 -0700	[thread overview]
Message-ID: <4DB86078.5060206@intel.com> (raw)
In-Reply-To: <1303928099.2242.2.camel@scimitar>


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


  reply	other threads:[~2011-04-27 18:29 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-27  3:00 Personal git repositories Darren Hart
2011-04-27  3:22 ` Bruce Ashfield
2011-04-27  3:57   ` Darren Hart
2011-04-27  4:37     ` Saul Wold
2011-04-27  4:56       ` Darren Hart
2011-04-27  4:39 ` Tom Zanussi
2011-04-27  4:53   ` Darren Hart
2011-04-27  5:05     ` Tom Zanussi
2011-04-27  6:35       ` Darren Hart
2011-04-27  7:56 ` Koen Kooi
2011-04-27 14:45   ` Darren Hart
2011-04-27 17:20     ` Elizabeth Flanagan
2011-04-27 18:14       ` Joshua Lock
2011-04-27 18:29         ` Elizabeth Flanagan [this message]
2011-04-27 21:03       ` Richard Purdie
2011-04-27 22:47         ` Darren Hart
2011-04-28  0:59           ` Bruce Ashfield
2011-04-28  3:12             ` Xianghua Xiao
2011-04-28  8:28             ` Richard Purdie
2011-04-28 14:56               ` Bruce Ashfield
2011-04-28 17:07               ` Darren Hart
2011-04-29  4:04           ` Darren Hart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DB86078.5060206@intel.com \
    --to=elizabeth.flanagan@intel.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.