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...
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.