On 01/19/2015 05:38 PM, 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. Yup, for e.g. in Storage SIG we are going have extra kernel modules , may be a rebuilt kernel in future. So we are having couple of SIGs which are having or going to have modified kernels. > 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. > I like #1, even if it is more work. I think it is logical thing to do as SIGs should not conflict with each other when a user consumes them. I mean one of the purpose of SIGs to improve the user experience for consuming stuffs that are not present in CentOS core. Having different build targets for each SIG I think complicate overall integration of different SIGs. I am sure there would be a lot of use cases when multiple SIGs would be used together. -Lala > On the whole I'm inclined to prefer #2. > > Thoughts? > > -George > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel