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?
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Quoted 19 lines · Darren Hart
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.
Quoted 6 lines
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
Quoted 1 line
Quoted 25 lines · Bruce Ashfield
Quoted 24 lines · Darren Hart
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.
Quoted 7 lines
Quoted 1 line
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
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Quoted 36 lines · Darren Hart
Quoted 25 lines · Bruce Ashfield
Quoted 24 lines · Darren Hart
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.
Quoted 7 lines
Quoted 1 line
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 :)
Quoted 6 lines
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!
Quoted 19 lines · Darren Hart
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.
Quoted 7 lines
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
Quoted 36 lines · Tom Zanussi
Quoted 19 lines · Darren Hart
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.
Quoted 7 lines
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.
Quoted 2 lines
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,
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Quoted 40 lines · Saul Wold
Quoted 39 lines · Darren Hart
Quoted 25 lines · Bruce Ashfield
Quoted 24 lines · Darren Hart
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.
Quoted 7 lines
Quoted 1 line
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:
Quoted 6 lines
Quoted 3 lines
git://git.yoctoproject.org/dvhart/meta-boottime.gitI 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.
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Quoted 63 lines · Darren Hart
Quoted 36 lines · Tom Zanussi
Quoted 19 lines · Darren Hart
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.
Quoted 7 lines
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.
Quoted 2 lines
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 anythingFor #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:
Quoted 8 lines
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...
Quoted 2 lines
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
Quoted 9 lines
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,
Quoted 78 lines · Tom Zanussi
Quoted 63 lines · Darren Hart
Quoted 36 lines · Tom Zanussi
Quoted 19 lines · Darren Hart
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.
Quoted 7 lines
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.
Quoted 2 lines
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 anythingFor #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:
Quoted 8 lines
a) add user branches:
master
bernard
dvhart/topicA
dvhart/topicB
tzanussi/topicA
tzanussi/topicDYeah, 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...
Quoted 5 lines
Quoted 2 lines
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
Quoted 14 lines
Tom
Quoted 9 lines
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,
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Op 27 apr 2011, om 05:00 heeft Darren Hart het volgende geschreven:
Quoted 19 lines
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.
Quoted 4 lines
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.
Have you though about setting up a gitorious instance on git.yocto?
Regards,
Koen
Quoted 22 lines · Koen Kooi
Op 27 apr 2011, om 05:00 heeft Darren Hart het volgende geschreven:
Quoted 19 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Have you though about setting up a gitorious instance on git.yocto?
I think that is a fantastic idea, it gets my vote.
gitorious++
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
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:
Use Case: Tomz has a branch of meta-intel that he has pushed to poky-contrib.git:tomz/foo. dvhart wants to look at it from his local repo:
git remote add poky-contrib ssh://[email protected]/poky-contrib.git git fetch poky-contrib tomz/foo:foo
git checkout foo
The fetch allows a sparse checkout of *just* tomz's branch. No need to download all 75M of poky-contrib which is what you would do with "git remote update". Git remote update is the wrong way to do this and I'd like to avoid having to swap infrastructure around when it seems to me that this is just one of those "git being a pain to learn"
-b
Quoted 38 lines · Darren Hart
Quoted 22 lines · Koen Kooi
Op 27 apr 2011, om 05:00 heeft Darren Hart het volgende geschreven:
Quoted 19 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Have you though about setting up a gitorious instance on git.yocto?
I think that is a fantastic idea, it gets my vote.
gitorious++
Signature · 4 lines
--------------- Elizabeth Flanagan Yocto Project Release Engineer
Quoted 4 lines · Elizabeth Flanagan
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*.
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.
Cheers,
Joshua
Signature · 3 lines
Joshua Lock
Yocto Build System Monkey
Intel Open Source Technology CentreQuoted 8 lines · Joshua Lock
Quoted 4 lines · Elizabeth Flanagan
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).
Quoted 3 lines
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
Quoted 8 lines · Elizabeth Flanagan
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:
Use Case: Tomz has a branch of meta-intel that he has pushed to poky-contrib.git:tomz/foo. dvhart wants to look at it from his local repo:
Quoted 7 lines
git remote add poky-contrib ssh://[email protected]/poky-contrib.git git fetch poky-contrib tomz/foo:foo
git checkout fooThe fetch allows a sparse checkout of *just* tomz's branch. No need to download all 75M of poky-contrib which is what you would do with "git remote update". Git remote update is the wrong way to do this and I'd like to avoid having to swap infrastructure around when it seems to me that this is just one of those "git being a pain to learn"
Just to add to this discussion, with gitolite, it should be easy to setup a yocto-contrib repo where each user "owns" the branches under <keyname>/*. This means as ssh keys are added, they'd automatically get their own "scratch" area. As Beth points out above, its perfectly possible to checkout branches and manipulate them as long as you know the commands.
This isn't a set of repos per user but when you think about this, how often do we really need that? Yes, some people like Bruce have usecases but I'm not sure they're typical and in those small number of cases I'm sure we can come up with some generic testing/dev repos to assist too. As soon as something grows to the point where the branch is problematic, it deserves its own repo and it should be properly namespaced, not user specific anyway.
Cheers,
Richard
Quoted 9 lines · Richard Purdie
Quoted 8 lines · Elizabeth Flanagan
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:
Use Case: Tomz has a branch of meta-intel that he has pushed to poky-contrib.git:tomz/foo. dvhart wants to look at it from his local repo:
I'm curious how many people reading this feel this is "basic git". Anyone willing to admit this was the first time they have seen a targeted branch fetch used to avoid a larger download? If everyone is comfortable with this, fine. If not, we should consider the impact of this type of access on our users.
Quoted 3 lines
Quoted 3 lines
git remote add poky-contrib ssh://[email protected]/poky-contrib.git git fetch poky-contrib tomz/foo:foo
git checkout foo
My biggest complaint with this is the lack of self discovery from within git without doing a git remote update. Unless tomz is online at the time to tell me it's tomz/foo-bar, not tomz/foo_bar, then I have to go load the web browser and check which branches are available, or resort to downloading all the objects.
I confess though, it still just feels wrong to keep unrelated source trees in the same repository.
Quoted 14 lines
Quoted 6 lines
The fetch allows a sparse checkout of *just* tomz's branch. No need to download all 75M of poky-contrib which is what you would do with "git remote update". Git remote update is the wrong way to do this and I'd like to avoid having to swap infrastructure around when it seems to me that this is just one of those "git being a pain to learn"
Just to add to this discussion, with gitolite, it should be easy to setup a yocto-contrib repo where each user "owns" the branches under <keyname>/*. This means as ssh keys are added, they'd automatically get their own "scratch" area. As Beth points out above, its perfectly possible to checkout branches and manipulate them as long as you know the commands.
Quoted 7 lines
This isn't a set of repos per user but when you think about this, how often do we really need that? Yes, some people like Bruce have usecases but I'm not sure they're typical and in those small number of cases I'm sure we can come up with some generic testing/dev repos to assist too. As soon as something grows to the point where the branch is problematic, it deserves its own repo and it should be properly namespaced, not user specific anyway.
I don't understand wanting to keep multiple distinct source trees in a single git repositorie. If you have two different layers in there, each in its own branch, then you can only work with one of them at a time. The end-user then has to have multiple clones of the same repository in order to work with their two layers. And they will end up naming them something like:
yocto-contrib-layer-1.git
yocto-contrib-layer-2.git
And keep them checked out to the appropriate set of branches... that seems like a lot of pain to impose on users to avoid setting up personal git repositories. Personally, I think I would revert to my kernel.org repositories rather than try and make this work.
Or - is my git-fu weak? Is there a better way to handle the above?
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Quoted 53 lines · Darren Hart
Quoted 9 lines · Richard Purdie
Quoted 8 lines · Elizabeth Flanagan
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:
Use Case: Tomz has a branch of meta-intel that he has pushed to poky-contrib.git:tomz/foo. dvhart wants to look at it from his local repo:
I'm curious how many people reading this feel this is "basic git". Anyone willing to admit this was the first time they have seen a targeted branch fetch used to avoid a larger download? If everyone is comfortable with this, fine. If not, we should consider the impact of this type of access on our users.
Quoted 3 lines
Quoted 3 lines
git remote add poky-contrib ssh://[email protected]/poky-contrib.git git fetch poky-contrib tomz/foo:foo
git checkout fooMy biggest complaint with this is the lack of self discovery from within git without doing a git remote update. Unless tomz is online at the time to tell me it's tomz/foo-bar, not tomz/foo_bar, then I have to go load the web browser and check which branches are available, or resort to downloading all the objects.
I confess though, it still just feels wrong to keep unrelated source trees in the same repository.
Quoted 14 lines
Quoted 6 lines
The fetch allows a sparse checkout of *just* tomz's branch. No need to download all 75M of poky-contrib which is what you would do with "git remote update". Git remote update is the wrong way to do this and I'd like to avoid having to swap infrastructure around when it seems to me that this is just one of those "git being a pain to learn"
Just to add to this discussion, with gitolite, it should be easy to setup a yocto-contrib repo where each user "owns" the branches under <keyname>/*. This means as ssh keys are added, they'd automatically get their own "scratch" area. As Beth points out above, its perfectly possible to checkout branches and manipulate them as long as you know the commands.
Quoted 7 lines
This isn't a set of repos per user but when you think about this, how often do we really need that? Yes, some people like Bruce have usecases but I'm not sure they're typical and in those small number of cases I'm sure we can come up with some generic testing/dev repos to assist too. As soon as something grows to the point where the branch is problematic, it deserves its own repo and it should be properly namespaced, not user specific anyway.
Quoted 8 lines
I don't understand wanting to keep multiple distinct source trees in a single git repositorie. If you have two different layers in there, each in its own branch, then you can only work with one of them at a time. The end-user then has to have multiple clones of the same repository in order to work with their two layers. And they will end up naming them something like:
yocto-contrib-layer-1.git
yocto-contrib-layer-2.git
This is what I was wondering as well. I had my meta-kernel-dev as a branch on poky-extras and ran into exactly this problem. Either have two clones, or get it into master. Master was the choice, since the other seemed clunky.
Maybe I'm misunderstanding as well, but sparse fetch or not (and yes I've done/used it), logically I like things that are distinct source trees to be separate repos. Maybe it's a kernel-guy thing ? :)
Cheers,
Bruce
Quoted 8 lines
And keep them checked out to the appropriate set of branches... that seems like a lot of pain to impose on users to avoid setting up personal git repositories. Personally, I think I would revert to my kernel.org repositories rather than try and make this work.
Or - is my git-fu weak? Is there a better way to handle the above?
most if not all meego repo is on gitorious, why can't Yocto leverage it, at least for now while everything is changing fast?
Xianghua
Quoted 113 lines · Bruce Ashfield
Quoted 79 lines · Darren Hart
Quoted 12 lines · Richard Purdie
Quoted 10 lines · Elizabeth Flanagan
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:Quoted 3 lines
Quoted 3 lines
Use Case: Tomz has a branch of meta-intel that he has pushed to poky-contrib.git:tomz/foo. dvhart wants to look at it from his local repo:
I'm curious how many people reading this feel this is "basic git". Anyone willing to admit this was the first time they have seen a targeted branch fetch used to avoid a larger download? If everyone is comfortable with this,
fine. If not, we should consider the impact of this type of access on our users.Quoted 3 lines
Quoted 3 lines
git remote add poky-contrib ssh://[email protected]/poky-contrib.git git fetch poky-contrib tomz/foo:foo
git checkout fooMy biggest complaint with this is the lack of self discovery from within git
without doing a git remote update. Unless tomz is online at the time to tell me
it's tomz/foo-bar, not tomz/foo_bar, then I have to go load the web browser and
check which branches are available, or resort to downloading all the objects.I confess though, it still just feels wrong to keep unrelated source trees in
the same repository.Quoted 17 lines
Quoted 9 lines
The fetch allows a sparse checkout of *just* tomz's branch. No need to download all 75M of poky-contrib which is what you would do with "git remote
update". Git remote update is the wrong way to do this and I'd like to avoid
having to swap infrastructure around when it seems to me that this is just
one of those "git being a pain to learn"Just to add to this discussion, with gitolite, it should be easy to setup a yocto-contrib repo where each user "owns" the branches under <keyname>/*. This means as ssh keys are added, they'd automatically get their own "scratch" area. As Beth points out above, its perfectly possible to checkout branches and manipulate them as long as you know the commands.
Quoted 7 lines
This isn't a set of repos per user but when you think about this, how often do we really need that? Yes, some people like Bruce have usecases but I'm not sure they're typical and in those small number of cases I'm sure we can come up with some generic testing/dev repos to assist too. As soon as something grows to the point where the branch is problematic, it deserves its own repo and it should be properly namespaced, not user specific anyway.
I don't understand wanting to keep multiple distinct source trees in a single
git repositorie. If you have two different layers in there, each in its own
branch, then you can only work with one of them at a time. The end-user then has
to have multiple clones of the same repository in order to work with their two
layers. And they will end up naming them something like:Quoted 2 lines
yocto-contrib-layer-1.git
yocto-contrib-layer-2.gitThis is what I was wondering as well. I had my meta-kernel-dev as a branch on poky-extras and ran into exactly this problem. Either have two clones, or get it into master. Master was the choice, since the other seemed clunky.
Maybe I'm misunderstanding as well, but sparse fetch or not (and yes I've done/used it), logically I like things that are distinct source trees to be separate repos. Maybe it's a kernel-guy thing ? :)
Cheers,
Bruce
Quoted 11 lines
And keep them checked out to the appropriate set of branches... that seems like
a lot of pain to impose on users to avoid setting up personal git repositories.
Personally, I think I would revert to my kernel.org repositories rather than try
and make this work.Or - is my git-fu weak? Is there a better way to handle the above?
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
Quoted 10 lines · Bruce Ashfield
Quoted 8 lines · Darren Hart
I don't understand wanting to keep multiple distinct source trees in a single git repositorie. If you have two different layers in there, each in its own branch, then you can only work with one of them at a time. The end-user then has to have multiple clones of the same repository in order to work with their two layers. And they will end up naming them something like:
yocto-contrib-layer-1.git
yocto-contrib-layer-2.git
Quoted 8 lines
This is what I was wondering as well. I had my meta-kernel-dev as a branch on poky-extras and ran into exactly this problem. Either have two clones, or get it into master. Master was the choice, since the other seemed clunky.
Maybe I'm misunderstanding as well, but sparse fetch or not (and yes I've done/used it), logically I like things that are distinct source trees to be separate repos. Maybe it's a kernel-guy thing ? :)
I think there are three elements to this:
a) People do like the logical separation that a repo gives them and find it easiest to think in those terms.
b) Most people are used to single relatively monolithic repos such as the kernel. People like myself who have used svn with multiple projects contained within like matchbox or the OpenedHand "misc" svn repo or the BSD projects approach to source control are probably in the minority.
c) The git tooling and all the examples out there are geared up to single repos. git is very much a tool where you need to think as its authors do.
Some of this can be addressed with clear example documentation about how to use git in this way.
Partly, these proposals are also working within the constraints of the git server solution we have too. Are we really in such a bad position that we need to change all the server setup over this or are there ways we can work within the existing system (or even extend gitolite)?
Cheers,
Richard
Quoted 22 lines · Richard Purdie
Quoted 10 lines · Bruce Ashfield
Quoted 8 lines · Darren Hart
I don't understand wanting to keep multiple distinct source trees in a single git repositorie. If you have two different layers in there, each in its own branch, then you can only work with one of them at a time. The end-user then has to have multiple clones of the same repository in order to work with their two layers. And they will end up naming them something like:
yocto-contrib-layer-1.git
yocto-contrib-layer-2.gitQuoted 8 lines
This is what I was wondering as well. I had my meta-kernel-dev as a branch on poky-extras and ran into exactly this problem. Either have two clones, or get it into master. Master was the choice, since the other seemed clunky.
Maybe I'm misunderstanding as well, but sparse fetch or not (and yes I've done/used it), logically I like things that are distinct source trees to be separate repos. Maybe it's a kernel-guy thing ? :)
I think there are three elements to this:
Quoted 10 lines
a) People do like the logical separation that a repo gives them and find it easiest to think in those terms.
b) Most people are used to single relatively monolithic repos such as the kernel. People like myself who have used svn with multiple projects contained within like matchbox or the OpenedHand "misc" svn repo or the BSD projects approach to source control are probably in the minority.
c) The git tooling and all the examples out there are geared up to single repos. git is very much a tool where you need to think as its authors do.
Agreed with the points above. git really is just wrangling a bunch of objects into commit chains and a branch points to a starting point. So I completely agree that all chains don't have to lead to the same origin, like you said, it is just how people tend to think.
Quoted 7 lines
Some of this can be addressed with clear example documentation about how to use git in this way.
Partly, these proposals are also working within the constraints of the git server solution we have too. Are we really in such a bad position that we need to change all the server setup over this or are there ways
I think we are likely ok, people have solutions that work, getting the right contrib repos setup with appropriate permissions to setup branches will go a long way.
As long as things stay responsive, I'd imagine that we'll find that people will be happy with things as they are. At least we've considered the options before it is critical.
Cheers,
Bruce
Quoted 8 lines
we can work within the existing system (or even extend gitolite)?
Cheers,
Richard
Quoted 22 lines · Richard Purdie
Quoted 10 lines · Bruce Ashfield
Quoted 8 lines · Darren Hart
I don't understand wanting to keep multiple distinct source trees in a single git repositorie. If you have two different layers in there, each in its own branch, then you can only work with one of them at a time. The end-user then has to have multiple clones of the same repository in order to work with their two layers. And they will end up naming them something like:
yocto-contrib-layer-1.git
yocto-contrib-layer-2.gitQuoted 8 lines
This is what I was wondering as well. I had my meta-kernel-dev as a branch on poky-extras and ran into exactly this problem. Either have two clones, or get it into master. Master was the choice, since the other seemed clunky.
Maybe I'm misunderstanding as well, but sparse fetch or not (and yes I've done/used it), logically I like things that are distinct source trees to be separate repos. Maybe it's a kernel-guy thing ? :)
I think there are three elements to this:
Quoted 10 lines
a) People do like the logical separation that a repo gives them and find it easiest to think in those terms.
b) Most people are used to single relatively monolithic repos such as the kernel. People like myself who have used svn with multiple projects contained within like matchbox or the OpenedHand "misc" svn repo or the BSD projects approach to source control are probably in the minority.
c) The git tooling and all the examples out there are geared up to single repos. git is very much a tool where you need to think as its authors do.
Agreed.
Quoted 7 lines
Some of this can be addressed with clear example documentation about how to use git in this way.
Partly, these proposals are also working within the constraints of the git server solution we have too. Are we really in such a bad position that we need to change all the server setup over this or are there ways we can work within the existing system (or even extend gitolite)?
I don't know what gitolite is capable of. I would really like to be able to create and destroy my own repositories in a central location with other Yocto developers.
However, this doesn't block me from moving forward. I can use kernel.org or dvhart.com to do this for the time being and make requests of the admins when I have a repository that looks to have some staying power. I'll have to time this transition appropriately so that I don't have to ask too many people to migrate to the new URL, but that would be true of a personal repository to official repository move as well.
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Quoted 17 lines · Darren Hart
Quoted 9 lines · Richard Purdie
Quoted 8 lines · Elizabeth Flanagan
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:
Use Case: Tomz has a branch of meta-intel that he has pushed to poky-contrib.git:tomz/foo. dvhart wants to look at it from his local repo:
I'm curious how many people reading this feel this is "basic git". Anyone willing to admit this was the first time they have seen a targeted branch fetch used to avoid a larger download? If everyone is comfortable with this, fine. If not, we should consider the impact of this type of access on our users.
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
git remote add poky-contrib ssh://[email protected]/poky-contrib.git git fetch poky-contrib tomz/foo:foo
git checkout fooMy biggest complaint with this is the lack of self discovery from within git without doing a git remote update. Unless tomz is online at the time to tell me it's tomz/foo-bar, not tomz/foo_bar, then I have to go load the web browser and check which branches are available, or resort to downloading all the objects.
I just realized another major issue I have with this approach. It doesn't just mean that I _can_ use git fetch to get a specific branch to avoid pulling in a massive pile of objects I don't need, it means I have to stop using "git remote update" entirely for everything else I do in that repository and I have to fetch all the other branches manually. The recommended approach here is VIRAL.
--
Darren
Quoted 44 lines
I confess though, it still just feels wrong to keep unrelated source trees in the same repository.
Quoted 14 lines
Quoted 6 lines
The fetch allows a sparse checkout of *just* tomz's branch. No need to download all 75M of poky-contrib which is what you would do with "git remote update". Git remote update is the wrong way to do this and I'd like to avoid having to swap infrastructure around when it seems to me that this is just one of those "git being a pain to learn"
Just to add to this discussion, with gitolite, it should be easy to setup a yocto-contrib repo where each user "owns" the branches under <keyname>/*. This means as ssh keys are added, they'd automatically get their own "scratch" area. As Beth points out above, its perfectly possible to checkout branches and manipulate them as long as you know the commands.
Quoted 7 lines
This isn't a set of repos per user but when you think about this, how often do we really need that? Yes, some people like Bruce have usecases but I'm not sure they're typical and in those small number of cases I'm sure we can come up with some generic testing/dev repos to assist too. As soon as something grows to the point where the branch is problematic, it deserves its own repo and it should be properly namespaced, not user specific anyway.
I don't understand wanting to keep multiple distinct source trees in a single git repositorie. If you have two different layers in there, each in its own branch, then you can only work with one of them at a time. The end-user then has to have multiple clones of the same repository in order to work with their two layers. And they will end up naming them something like:
yocto-contrib-layer-1.git
yocto-contrib-layer-2.gitAnd keep them checked out to the appropriate set of branches... that seems like a lot of pain to impose on users to avoid setting up personal git repositories. Personally, I think I would revert to my kernel.org repositories rather than try and make this work.
Or - is my git-fu weak? Is there a better way to handle the above?
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel