I mashed send without finishing the thought. Not enough coffee yet today. On 01/19/2015 08:37 AM, Jim Perrin wrote: > > > On 01/19/2015 06:08 AM, George Dunlap wrote: >> At the moment, we're essentially using yum repos as the "patch" >> mechanism to CentOS Base: SIGs populate a repo with packages they want >> to add / override, and all other packages default to Base. >> >> The current setup is that every sig has exactly one production repo >> per CentOS version. >> >> Also, we seem to be wanting to see SIGs not as individual projects, >> but to make the 'G' an actual "group": so, for instance, the Virt SIG >> has both Xen and Docker, and we've recently approved oVirt. >> >> But there's a bit of a conflict here: what if one project in the SIG >> wants to use the package from Base, and another project in the SIG >> wants to use a custom-built package? Or what if both projects want to >> customize their packages in different ways? >> >> In particular: the Docker project in the Virt SIG wants to supply >> updated versions of Docker; but at the moment uses the kernel package >> from Base. The Xen project, on the other hand, needs to supply a >> different kernel package that has dom0 support enabled. >> >> Up until this point, this hasn't been an issue because I've been doing >> Xen development in virt6-testing, and Lokesh has been doing Docker >> development in virt7-testing. But I'm hoping to get Xen for CentOS 7 >> out soon, and I was just about to upload the Xen kernel to the CBS, >> when it occurred to me that if I did so, then everyone using the >> virt7-testing repo for Docker would suddenly get my updated kernel as >> well. >> >> So it seems we have a couple of ways to approach it. >> >> 1. Keep it one repo per SIG, and make all projects in a SIG sort out >> shared dependencies. >> >> 2. Allow one repo per *project* within a SIG (e.g., virt6-xen, virt7-docker) >> >> 3. Have some alternate way of doing a "patch", instead of repos. >> >> In the case of xen / docker, I haven't talked with Lokesh about this >> at all; it may be that he's fine with sharing a kernel with Xen. But >> it does increase the workload: now Lokesh needs to maintain the Docker >> side of the kernel, whereas before they could just rely on our >> upstream to do a lot of that testing. Furthermore, it increases the >> complexity of development and testing: before when doing kernel work, >> I could just test Xen; now the kernel needs to be tested by both Xen >> and Docker. And finally, now users of both projects get a kernel >> update whenever either one does. >> >> Which, of course, is pretty much the same as any other distro; but as >> a whole, at the moment at least, we have a lot less resources than any >> other distro our size and popularity. >> >> On the whole I'm inclined to prefer #2. >> > > I believe option 2 was always the plan, with a few caveats. > > 1. We start with one repo to test procedures and make sure things are > working that way first. > > 2. We work to keep repo sprawl to a minimum, lest sigs start creating a > few dozen project repos when just a couple will do. 3. We work to consolidate common packages as appropriate in a shared repository. There is still some ongoing debate as to if this would be epel, Extras, or would require the creation of a sig-common repo. If a sig requires a version that cannot be shared, this should be documented and the sig would need to carry that lib in their repo(s). -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77