[CentOS-devel] SIG repo layout and conflicts between projects within a SIG

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