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
_______________________________________________
CentOS-virt mailing list
CentOS-virt@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos-virt
