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. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77