[Engine-devel] New oVirt GIT Repo Request

[Keith Robertson]

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.
Cheers