Re: [Engine-devel] New oVirt GIT Repo Request

On 02/13/2012 10:57 AM, Douglas Landgraf wrote: > On 02/13/2012 07:31 AM, Barak Azulay wrote: >> On 02/12/2012 03:32 PM, Keith Robertson wrote: >>> On 02/11/2012 05:41 PM, Itamar Heim wrote: >>>> On 02/10/2012 04:42 PM, Keith Robertson wrote: >>>>> All, >>>>> >>>>> I would like to move some of the oVirt tools into their own GIT >>>>> repos so >>>>> that they are easier to manage/maintain. In particular, I would >>>>> like to >>>>> move the ovirt-log-collector, ovirt-iso-uploader, and >>>>> ovirt-image-uploader each into their own GIT repos. >>>>> >>>>> The Plan: >>>>> Step 1: Create naked GIT repos on oVirt.org for the 3 tools. >>>>> Step 2: Link git repos to gerrit. >>>> >>>> above two are same step - create a project in gerrit. >>>> I'll do that if list doesn't have any objections by monday. >>> Sure, np. >>>> >>>>> Step 3: Populate naked GIT repos with source and build standalone >>>>> spec >>>>> files for each. >>>>> Step 4: In one patch do both a) and b)... >>>>> a) Update oVirt manager GIT repo by removing tool source. >>>>> b) Update oVirt manager GIT repo such that spec has dependencies on 3 >>>>> new RPMs. >>>>> >>>>> Optional: >>>>> - These three tools share some python classes that are very >>>>> similar. I >>>>> would like to create a GIT repo (perhaps ovirt-tools-common) to >>>>> contain >>>>> these classes so that a fix in one place will fix the issue >>>>> everywhere. >>>>> Perhaps we can also create a naked GIT repo for these common classes >>>>> while addressing the primary concerns above. >>>> >>>> would this hold both python and java common code? >>> >>> None of the 3 tools currently have any requirement for Java code, but I >>> think the installer does. That said, I wouldn't have a problem mixing >>> Java code in the "common" component as long as they're in separate >>> package directories. >>> >>> If we do something like this do we want a "python" common RPM and a >>> "java" common RPM or just a single RPM for all common code? I don't >>> really have a preference. >> >> I would go with separating the java common and python common, even if >> it's just to ease build/release issues. >> > +1 and if needed one package be required to the other. > Sounds like a plan. Full speed ahead.