[yocto] Notes from April 26th Yocto Technical Team meeting
All, Here are the notes from the Yocto Technical Team meeting on April 26th. Let me know if you have any changes or corrections. Thanks. - Julie Attendees: Beth, Darren, Tom, Joshua, Julie, Dave, Jessica, Saul, Jeff Polk, Bruce Agenda: 1) Review Yocto Project 1.1 Release Criteria See - https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.1_Release_Criteria#Yocto_Project_1.1 for updates. Action Items: Julie: Add query to Open Bugs. Saul: Assign Richard's NEW bugs to the correct owners. Julie: Send team an email regarding ACCEPTing NEW bugs (or letting the team know if High priority bugs can't be fixed by M1). Bruce: Check in with team on bugs 414 and 609. Saul: Check in with Dexuan on bug 828 since it hasn't been worked on in a month. 2) Review Yocto Project 1.0.1 Release Criteria See https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.1_Release_Criteria#Yocto_Project_1.0.1 for status 3) Open: Team discussed creating an overall calendar to view status. Wiki calendar and Google calendar were brought up as possibilities. The team would like to add 1.1, 1.0.1, and possibly conferences (this TBD because it is already on the Linux Foundation website). Team will define approach off-line. Darren will kick-off an email with some options. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto] RFC: Image Creator and Config Creator, design thoughts
On 11-04-22 11:10 AM, Tom Zanussi wrote: On Thu, 2011-04-21 at 09:05 -0700, Darren Hart wrote: I sat down with Josh earlier this week to discuss how I might use the Image Creator in my development and to address any issues that might pose as blockers to my finding such a tool useful. This led to various feature discussions, scope setting, etc. I wanted to capture that here and also ask for comments from other users and developers. Image Recipe Generation --- The image creator Josh is working on currently facilitates specifying the policy (bitbake term "distro", such as poky, poky-bleeding, or poky-lsb), image, and any additional packages you may want to include. It then provides a simple wrapper to bitbake and it's output. This is useful in and of itself as sorting out which variables to modify (IMAGE_INSTALL, MACHINE(_ESSENTIAL?)_R?DEPENDS_append(_$MACHINE), etc) and which tasks to rebuild (task_base, task_machine_base, poky-image-*, etc.) can be a frustrating exercise (or at least it has been for me). In order for this feature to be the most useful, it needs to be able to save the result of the user's selection. This involves saving off the "distro" selection (typically in local.conf) as well as an image recipe defining which packages to include in the resulting image. This could be done by writing to local.conf and saving a new *image*.bb file in a suitable location. Writing Layers -- The suitable location is most likely a layer, which suggests the Image Builder should probably know how to construct a basic layer skeleton and prompt the user to fill in the descriptive bits required for layer.conf. I could see this as having been useful for the recent Yocto Project 1.0 launch demo we worked on, which added rygel upnp video renderers to the the 0.9 audio only demo. This implies the Image Builder should also be able to work with an existing layer - perhaps only those that it created - and save the changes back to that layer. Configuration Fragments --- In order to properly build the demo images (poky-image-rygel specifically) some specific license related variables need to be set, typically in local.conf: COMMERCIAL_LICENSE = "" COMMERCIAL_AUDIO_PLUGINS ?= "gst-plugins-ugly-mad gst-plugins-ugly-mpegaudioparse" COMMERCIAL_VIDEO_PLUGINS ?= "gst-plugins-ugly-mpeg2dec gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse" Without the above, the upnp demo is mostly non-functional. Having to manually add these sorts of settings significantly reduces the value of the Image Builder in my mind. This led to the discussion of providing a graphical mechanism to set the variables that have some impact on how the generated image recipe is built. Something like a Linux kernel kconfig mechanism, which only shows the user relevant options (albeit still WAY too many), might be really nice here. Perhaps an interface that parsed the recipes included in the image recipe and determined which variables would be relevant to the user and present those in the UI with help derived from documentation.conf doctags (or perhaps a new mechanism). Input we got from the ELC talk suggested that people did think it would be intuitive and useful to expand the kernel menuconfig 'UI' down to all the other packages in the image. I've used UIs designed like that in other build systems and it was very useful, so I'd add my +1 to the ELC requests... And I'd add another +1 to that. Bruce Tom As this would be a considerable effort, and would surely delay the progress of the image builder itself, perhaps a Configuration Editor would be a good companion tool which the Image Builder could launch to do the relevant configurations Conclusions --- The goal of any user interface should be to abstract away to implementation details that are not particularly relevant to task at hand, or to the user's perception of the task at hand. I feel these tools as discussed above would help contain feature creep, while still allowing for a more complete graphical interface to configuring and building images. Thoughts? Criticisms? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto] RFC: Image Creator and Config Creator, design thoughts
On 04/26/2011 11:40 AM, Bruce Ashfield wrote: > On 11-04-22 11:10 AM, Tom Zanussi wrote: >> On Thu, 2011-04-21 at 09:05 -0700, Darren Hart wrote: >>> I sat down with Josh earlier this week to discuss how I might use the >>> Image Creator in my development and to address any issues that might >>> pose as blockers to my finding such a tool useful. This led to various >>> feature discussions, scope setting, etc. I wanted to capture that here >>> and also ask for comments from other users and developers. >>> >>> >>> Image Recipe Generation >>> --- >>> The image creator Josh is working on currently facilitates specifying >>> the policy (bitbake term "distro", such as poky, poky-bleeding, or >>> poky-lsb), image, and any additional packages you may want to include. >>> It then provides a simple wrapper to bitbake and it's output. This is >>> useful in and of itself as sorting out which variables to modify >>> (IMAGE_INSTALL, MACHINE(_ESSENTIAL?)_R?DEPENDS_append(_$MACHINE), etc) >>> and which tasks to rebuild (task_base, task_machine_base, poky-image-*, >>> etc.) can be a frustrating exercise (or at least it has been for me). >>> >>> In order for this feature to be the most useful, it needs to be able to >>> save the result of the user's selection. This involves saving off the >>> "distro" selection (typically in local.conf) as well as an image recipe >>> defining which packages to include in the resulting image. This could be >>> done by writing to local.conf and saving a new *image*.bb file in a >>> suitable location. >>> >>> >>> Writing Layers >>> -- >>> The suitable location is most likely a layer, which suggests the Image >>> Builder should probably know how to construct a basic layer skeleton and >>> prompt the user to fill in the descriptive bits required for layer.conf. >>> >>> I could see this as having been useful for the recent Yocto Project 1.0 >>> launch demo we worked on, which added rygel upnp video renderers to the >>> the 0.9 audio only demo. This implies the Image Builder should also be >>> able to work with an existing layer - perhaps only those that it created >>> - and save the changes back to that layer. >>> >>> >>> Configuration Fragments >>> --- >>> In order to properly build the demo images (poky-image-rygel >>> specifically) some specific license related variables need to be set, >>> typically in local.conf: >>> >>> COMMERCIAL_LICENSE = "" >>> COMMERCIAL_AUDIO_PLUGINS ?= "gst-plugins-ugly-mad >>> gst-plugins-ugly-mpegaudioparse" >>> COMMERCIAL_VIDEO_PLUGINS ?= "gst-plugins-ugly-mpeg2dec >>> gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse" >>> >>> Without the above, the upnp demo is mostly non-functional. Having to >>> manually add these sorts of settings significantly reduces the value of >>> the Image Builder in my mind. This led to the discussion of providing a >>> graphical mechanism to set the variables that have some impact on how >>> the generated image recipe is built. >>> >>> Something like a Linux kernel kconfig mechanism, which only shows the >>> user relevant options (albeit still WAY too many), might be really nice >>> here. Perhaps an interface that parsed the recipes included in the image >>> recipe and determined which variables would be relevant to the user and >>> present those in the UI with help derived from documentation.conf >>> doctags (or perhaps a new mechanism). >>> >> >> Input we got from the ELC talk suggested that people did think it would >> be intuitive and useful to expand the kernel menuconfig 'UI' down to all >> the other packages in the image. >> >> I've used UIs designed like that in other build systems and it was very >> useful, so I'd add my +1 to the ELC requests... > > And I'd add another +1 to that. > So the kernel guys agree that menuconfig should used everywhere. Surprise, Surprise. ;-) -- Darren > Bruce > >> >> Tom >> >>> As this would be a considerable effort, and would surely delay the >>> progress of the image builder itself, perhaps a Configuration Editor >>> would be a good companion tool which the Image Builder could launch to >>> do the relevant configurations >>> >>> >>> Conclusions >>> --- >>> The goal of any user interface should be to abstract away to >>> implementation details that are not particularly relevant to task at >>> hand, or to the user's perception of the task at hand. I feel these >>> tools as discussed above would help contain feature creep, while still >>> allowing for a more complete graphical interface to configuring and >>> building images. >>> >>> >>> Thoughts? Criticisms? >>> >>> >> >> >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > > -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org
[yocto] Personal git repositories
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? -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Personal git repositories
On 11-04-26 11:00 PM, 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? Only a 2nd vote for something like this. I've had a need for this on several occasions, and often I'd like to get something out, and then slot it into a more "official" location later. My current location for the 2.6.39-yocto kernel on my kernel.org account sort of says it all :) Cheers, Bruce ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Personal git repositories
On 04/26/2011 08:22 PM, Bruce Ashfield wrote: > On 11-04-26 11:00 PM, 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? > > Only a 2nd vote for something like this. I've had a need for > this on several occasions, and often I'd like to get something out, and > then slot it into a more "official" location later. My current > location for the 2.6.39-yocto kernel on my kernel.org account sort > of says it all :) Right. I just pushed meta-boottime to my kernel.org account as well. I'd much rather have that be: git://git.yoctoproject.org/dvhart/meta-boottime.git -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Personal git repositories
On 04/26/2011 08:57 PM, Darren Hart wrote: On 04/26/2011 08:22 PM, Bruce Ashfield wrote: On 11-04-26 11:00 PM, 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? Only a 2nd vote for something like this. I've had a need for this on several occasions, and often I'd like to get something out, and then slot it into a more "official" location later. My current location for the 2.6.39-yocto kernel on my kernel.org account sort of says it all :) Right. I just pushed meta-boottime to my kernel.org account as well. I'd much rather have that be: git://git.yoctoproject.org/dvhart/meta-boottime.git I also think this is a good idea, but can we wait until we get things transitioned to the new server and stabilized before adding new things right now? Sau! ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Personal git repositories
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... Tom ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Personal git repositories
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 b) use the personal repositories described in #2 above 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 yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Personal git repositories
On 04/26/2011 09:37 PM, Saul Wold wrote: > On 04/26/2011 08:57 PM, Darren Hart wrote: >> >> >> On 04/26/2011 08:22 PM, Bruce Ashfield wrote: >>> On 11-04-26 11:00 PM, 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? >>> >>> Only a 2nd vote for something like this. I've had a need for >>> this on several occasions, and often I'd like to get something out, and >>> then slot it into a more "official" location later. My current >>> location for the 2.6.39-yocto kernel on my kernel.org account sort >>> of says it all :) >> >> Right. I just pushed meta-boottime to my kernel.org account as well. I'd >> much rather have that be: >> >> git://git.yoctoproject.org/dvhart/meta-boottime.git >> >> > I also think this is a good idea, but can we wait until we get things > transitioned to the new server and stabilized before adding new things > right now? I believe so. Bruce and I can use kernel.org for now. Tom and I can use personal branches in meta-intel. But I'd like to see a solution here before we see widespread use of kernel.org and github to manage git trees as it will be collectively a lot more work to move people to the new infrastructure - and we'll lose some mindshare in the meantime. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Personal git repositories
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... 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, > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Personal git repositories
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 P
