On 05/17/2014 12:01 AM, Kay Williams wrote: > * making newer software versions available in a single repository (e.g. > centos-plus) quickly becomes messy because users may not want/trust every > new thing in that repository, and then they have to use > includepkgs/excludepkgs in yum repo definitions to limit what they see. It's > cleaner/easier to add/remove repos. but the flip side is that if components arent consolidating the user experience, there is no assurance and no relationship with anything else. And this hurts from both the top end of the stack, user facing ui apps, and from the bottom end infra or system libs, in this case qpid. Working with a single consolidated ( or maybe a few consolidated) repos means that people are unable to arbitarily 'transmorgify', without first setting some level of expectation with other components that might rely on a specific state. Packaging is hard, sure - and it gets dramatically harder when executing without a policy framework. The includepkg / exclude process is also not easy, neither is the costs nor priorities, they all come with their own wins and pains. Also worth noting is that SIG's dont map to repos - many ( most so far ) are likely going to opt to deliver into a common set of repos, making it easier for others to consume components, specially the infra level SIGs like Virt / Storage etc. So we need to address this issue either way, sooner the better Also, top posting :( -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc