On 03/19/2015 02:46 PM, George Dunlap wrote:> On Thu, Mar 19, 2015 at 2:39 PM, Karanbir Singh <mail-lists at karan.org> wrote: >> On 03/19/2015 12:23 PM, George Dunlap wrote: >>> On Thu, Mar 19, 2015 at 12:20 PM, Sandro Bonazzola <sbonazzo at redhat.com> wrote: >>>> Hi, >>>> following Cloud SIG example[1] I would like to start defining the CBS tags hierarchy for Virt SIG. >>>> >>>> For opening the discussion I suggest: >>>> >>>> - virt${release}-common : packages not related to xen or kvm, used by at least 2 projects >>>> - virt${release}-xen : xen hypervisor related packages >>>> - virt${release}-kvm : kvm hypervisor related packages (like qemu-kvm-ev) >>>> - virt${release}-ovirt : ovirt packages and dependencies, not required by other projects >>>> - virt${release}-docker : docker packages and dependencies, not required by other projects >>> >>> Looks reasonable at first blush. >>> >>> -George >>> _______________________________________________ >>> CentOS-virt mailing list >>> CentOS-virt at centos.org >>> http://lists.centos.org/mailman/listinfo/centos-virt >>> >> >> note that we want git branch, koji builds, release tags and test >> project, sign request queue and release process to map to a single >> 'TAG', will this still work ? > > I think so... I'm not sure what else we might want. >how would we sync the different branch names ? note: the proposal here is going to result in ~ 24 different branches for each target ( into git.centos.org ) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc
Il 20/03/2015 11:29, Karanbir Singh ha scritto:> On 03/19/2015 02:46 PM, George Dunlap wrote: >> On Thu, Mar 19, 2015 at 2:39 PM, Karanbir Singh <mail-lists at karan.org> wrote: >>> On 03/19/2015 12:23 PM, George Dunlap wrote: >>>> On Thu, Mar 19, 2015 at 12:20 PM, Sandro Bonazzola <sbonazzo at redhat.com> wrote: >>>>> Hi, >>>>> following Cloud SIG example[1] I would like to start defining the CBS tags hierarchy for Virt SIG. >>>>> >>>>> For opening the discussion I suggest: >>>>> >>>>> - virt${release}-common : packages not related to xen or kvm, used by at least 2 projects >>>>> - virt${release}-xen : xen hypervisor related packages >>>>> - virt${release}-kvm : kvm hypervisor related packages (like qemu-kvm-ev) >>>>> - virt${release}-ovirt : ovirt packages and dependencies, not required by other projects >>>>> - virt${release}-docker : docker packages and dependencies, not required by other projects >>>> >>>> Looks reasonable at first blush. >>>> >>>> -George >>>> _______________________________________________ >>>> CentOS-virt mailing list >>>> CentOS-virt at centos.org >>>> http://lists.centos.org/mailman/listinfo/centos-virt >>>> >>> >>> note that we want git branch, koji builds, release tags and test >>> project, sign request queue and release process to map to a single >>> 'TAG', will this still work ? >> >> I think so... I'm not sure what else we might want. >> > > how would we sync the different branch names ? > > note: the proposal here is going to result in ~ 24 different branches > for each target ( into git.centos.org ) >We can reduce it a bit, just keeping virt7-ovirt instead of virt${release}-ovirt; no plan to get it on el6 right now. We can also drop common if we decide to provide the same rpm in 2 or more different projects repo. I'm not sure it's wise to do the same for the kvm target. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
On 03/20/2015 10:42 AM, Sandro Bonazzola wrote:>>>>>> For opening the discussion I suggest: >>>>>> >>>>>> - virt${release}-common : packages not related to xen or kvm, used by at least 2 projects >>>>>> - virt${release}-xen : xen hypervisor related packages >>>>>> - virt${release}-kvm : kvm hypervisor related packages (like qemu-kvm-ev) >>>>>> - virt${release}-ovirt : ovirt packages and dependencies, not required by other projects >>>>>> - virt${release}-docker : docker packages and dependencies, not required by other projects >>>>> >> note: the proposal here is going to result in ~ 24 different branches >> for each target ( into git.centos.org ) >> > > We can reduce it a bit, just keeping virt7-ovirt instead of virt${release}-ovirt; no plan to get it on el6 right now.Can you detail the ovirt plan for the Virt SIG - so far, I dont think we've seen any ovirt content at all. Apologies if I've missed a conversation in the past around this, feel free to point me at that instead if its easier.> We can also drop common if we decide to provide the same rpm in 2 or more different projects repo. > I'm not sure it's wise to do the same for the kvm target.The key thing here to keep in mind is that we want the auth and acl process to be simple for the entire pipeline. This starts from Git all the way to having released content on the mirrors. Take a look at this as an example of what the entire pipeline looks like : ref: http://lists.centos.org/pipermail/centos-devel/attachments/20150316/e6b4b15d/attachment.png Given that SIG subslipts are going to be an issue ( and are for Storage and Cloud infra SIG, in addition to the Virt SIG already ), we might need to rethink that a bit, hence my question on how this mapping will work. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc
On Fri, Mar 20, 2015 at 10:29 AM, Karanbir Singh <mail-lists at karan.org> wrote:> how would we sync the different branch names ?Sorry, I don't understand this question.> note: the proposal here is going to result in ~ 24 different branches > for each target ( into git.centos.org )Sorry again for being a bit dense, but I'm not seeing the math here. According to the diagram you link to below, the structure would be rpms/[package].git sigvirt-{common,xen,kvm,docker,ovirt}/{6,7}, which would give us 10 total targets and branches, of which each individual group will only need to have access to 1-2 (common and xen probably for me, docker for lokesh, ovirt and kvm for Sandro & co). What am I missing? And is there any other way to break it down such that each of the projects (Docker, Xen, oVirt) can update common packages like the kernel without stepping on each others' toes? -George