From: Darren Hart <dvhart@linux.intel.com>
To: Tom Zanussi <tom.zanussi@intel.com>
Cc: Yocto Project <yocto@yoctoproject.org>
Subject: Re: Personal git repositories
Date: Tue, 26 Apr 2011 23:35:07 -0700 [thread overview]
Message-ID: <4DB7B91B.3050203@linux.intel.com> (raw)
In-Reply-To: <1303880757.2593.238.camel@elmorro>
On 04/26/2011 10:05 PM, Tom Zanussi wrote:
> On Tue, 2011-04-26 at 21:53 -0700, Darren Hart wrote:
>>
>> On 04/26/2011 09:39 PM, Tom Zanussi wrote:
>>> On Tue, 2011-04-26 at 20:00 -0700, Darren Hart wrote:
>>>> git.yoctoproject.org hosts a number of different repositories, some of
>>>> which host limited user contributions (such as poky-contrib). These
>>>> repositories are setup and administered by a yoctoproject.org system admin.
>>>>
>>>> As our developer base grows, the need for user creatable git trees also
>>>> grows. Eventually, *-contrib isn't going to scale, and neither will the
>>>> system admin. There are plenty of available places individuals can
>>>> create publicly accessible trees (github, kernel.org, or any number of
>>>> similar sites). However, I think it would be beneficial for at least
>>>> very active developers to be able to create and destroy trees on a whim,
>>>> without having to involve the system admin with each event.
>>>>
>>>> kernel.org provides a git web interface for user created trees. I'd like
>>>> to see something similar available at yoctoproject.org in order to
>>>> establish single place to go looking for "yocto developer trees". Users
>>>> would have to justify their request for a user account and agree to a
>>>> terms of use. This has served the Linux kernel community very well. I
>>>> think it could do the same for us.
>>>>
>>>> Note: I am not offering to setup such a service or even say that it's
>>>> possible with the current resources. I just wanted to throw the idea out
>>>> there and see if others have found a similar gap in the development
>>>> environment and if this idea would address that gap.
>>>>
>>>> Thoughts?
>>>>
>>>
>>> My thinking (I guess - I didn't really think that much about it at the
>>> time) when requesting the meta-intel-contrib repo was that repos that
>>> could expect to get continual contributions from many people would
>>> benefit from having a corresponding -contrib version - so far that's
>>> poky-contrib, linux-yocto-*.contrib, and openembedded-core-contrib. To
>>> me bsp repos fit the same criteria, but I'm not the one who has to
>>> manage it all, so I understand the desire to avoid the proliferation.
>>>
>>> Seems like the personal repos idea would mitigate the problem...
>>>
>>
>> I think these are two distinct but overlapping problems:
>>
>> 1) place to share on the common core (poky, linux-yocto*)
>> 2) place to share new stuff that may not amount to anything
>>
>> For #1, the *-contrib git repositories make sense to me. It provides a
>> single repository that a lot of people use and reduces the git remote
>> management for everyone. They are therefor worth the added complexity
>> they add to the yoctoproject git namespace and on the system administrator.
>>
>> For #2, people need to be able to prepare a tree and poke someone in IRC
>> with a git URL to try out. Many of these are likely to be short lived,
>> and to only have a single contributor. As such, they are not worth
>> polluting the yoctoproject git namespace, nor should we burden our
>> system admin with setting them up and tearing them down. Indeed, they
>> are likely to linger, continuing to pollute the namespace long after
>> they are dead trees simply due to the overhead of removing them!
>>
>> As for BSP's... these don't seem to have a lot of contributors - at
>> least from what I have seen. Typically 1 or 2 people. For that scenario,
>> I see two processes as options:
>>
>> a) add user branches:
>> master
>> bernard
>> dvhart/topicA
>> dvhart/topicB
>> tzanussi/topicA
>> tzanussi/topicD
>>
>
> Yeah, that's what you and I do already. But we now have people coming
> online who will be be continually pushing changes to their bsps in
> meta-intel and we don't necessarily want to give them write access to
> meta-intel itself right away, I assume...
>
>> b) use the personal repositories described in #2 above
>>
>
> Yeah, so we could create and manage meta-intel-contrib ourselves without
> bothering any admins...
Well, sort of. The personal trees would be writable only by their owner.
Otherwise you would have to manage all the user authentication. I forgot
about the new meta-intel contributors.
I would suggest we start with a pull model to get things upstream. As
they gain confidence in contributing, we can look at something where
they have more control of a repository, probably still will need a
meta-intel-contrib in this case.
--
Darren
>
> Tom
>
>> While it is possible to use poky-contrib for things like this, I think
>> it is non-intuitive to use a repository as a remote to a repository that
>> isn't based off the remote repository (like BSP layers which aren't part
>> of poky). For most users, this will result in pulling down MBs of
>> unnecessary git objects. Yes, you can use --reference when cloning. Yes,
>> you can use fancy fetch commands. No, nobody will.
>>
>> Thanks,
>>
>
>
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
next prev parent reply other threads:[~2011-04-27 6:35 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 [this message]
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
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=4DB7B91B.3050203@linux.intel.com \
--to=dvhart@linux.intel.com \
--cc=tom.zanussi@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.