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 _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
