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

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