8:42 a.m.
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.
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.
Please comment,
Keith Robertson
1:33 p.m.
Hi,
a suggestion for the plan: you could use git filter-branch with the
--subdirectory-filter option for creating the repos at step 1. That way
it will keep commit history of the files being moved in the new repos.
Paulo de Rezende Pinatti
Staff Software Engineer
IBM Linux Technology Center
On 02/10/2012 12: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.
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.
Please comment,
Keith Robertson
_______________________________________________
Arch mailing list
Arch(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/arch
2:48 a.m.
--Apple-Mail-7402373A-C19A-4425-B89A-E12094770920
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On 10 Feb 2012, at 16:42, Keith Robertson <kroberts(a)redhat.com> wrote:
All,
=20
I would like to move some of the oVirt tools into their own GIT repos so t=
hat
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 i=
nto their own GIT repos.
=20
The Plan:
Step 1: Create naked GIT repos on oVirt.org for the 3 tools.
Step 2: Link git repos to gerrit.
Step 3: Populate naked GIT repos with source and build standalone spec fil=
es 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 R=
PMs.
=20
Optional:
- These three tools share some python classes that are very similar. I wo=
uld
like to create a GIT repo (perhaps ovirt-tools-common) to contain these c=
lasses 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 t=
he primary concerns above.
+1 on the entire suggestion.
about the common stuff- will this package be obsolete once the tools will be=
base on the sdk?
=20
Please comment,
Keith Robertson
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--Apple-Mail-7402373A-C19A-4425-B89A-E12094770920
Content-Transfer-Encoding: base64
Content-Type: text/html;
charset=utf-8
PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+PGRpdiBzdHls
ZT0idGV4dC1hbGlnbjogbGVmdDtkaXJlY3Rpb246IGx0cjsgIj48YnI+PC9kaXY+PC9kaXY+PGRp
dj5PbiAxMCBGZWIgMjAxMiwgYXQgMTY6NDIsIEtlaXRoIFJvYmVydHNvbiAmbHQ7PGEgaHJlZj0i
bWFpbHRvOmtyb2JlcnRzQHJlZGhhdC5jb20iPmtyb2JlcnRzQHJlZGhhdC5jb208L2E+Jmd0OyB3
cm90ZTo8YnI+PGJyPjwvZGl2PjxkaXY+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRp
dj48c3Bhbj5BbGwsPC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPkkgd291bGQgbGlr
ZSB0byBtb3ZlIHNvbWUgb2YgdGhlIG9WaXJ0IHRvb2xzIGludG8gdGhlaXIgb3duIEdJVCByZXBv
cyBzbyB0aGF0IHRoZXkgYXJlIGVhc2llciB0byBtYW5hZ2UvbWFpbnRhaW4uICZuYnNwO0luIHBh
cnRpY3VsYXIsIEkgd291bGQgbGlrZSB0byBtb3ZlIHRoZSBvdmlydC1sb2ctY29sbGVjdG9yLCBv
dmlydC1pc28tdXBsb2FkZXIsIGFuZCBvdmlydC1pbWFnZS11cGxvYWRlciBlYWNoIGludG8gdGhl
aXIgb3duIEdJVCByZXBvcy48L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+VGhlIFBs
YW46PC9zcGFuPjxicj48c3Bhbj5TdGVwIDE6IENyZWF0ZSBuYWtlZCBHSVQgcmVwb3Mgb24gPGEg
aHJlZj0iaHR0cDovL29WaXJ0Lm9yZyI+b1ZpcnQub3JnPC9hPiBmb3IgdGhlIDMgdG9vbHMuPC9z
cGFuPjxicj48c3Bhbj5TdGVwIDI6IExpbmsgZ2l0IHJlcG9zIHRvIGdlcnJpdC48L3NwYW4+PGJy
PjxzcGFuPlN0ZXAgMzogUG9wdWxhdGUgbmFrZWQgR0lUIHJlcG9zIHdpdGggc291cmNlIGFuZCBi
dWlsZCBzdGFuZGFsb25lIHNwZWMgZmlsZXMgZm9yIGVhY2guPC9zcGFuPjxicj48c3Bhbj5TdGVw
IDQ6IEluIG9uZSBwYXRjaCBkbyBib3RoIGEpIGFuZCBiKS4uLjwvc3Bhbj48YnI+PHNwYW4+IGEp
IFVwZGF0ZSBvVmlydCBtYW5hZ2VyIEdJVCByZXBvIGJ5IHJlbW92aW5nIHRvb2wgc291cmNlLjwv
c3Bhbj48YnI+PHNwYW4+IGIpIFVwZGF0ZSBvVmlydCBtYW5hZ2VyIEdJVCByZXBvIHN1Y2ggdGhh
dCBzcGVjIGhhcyBkZXBlbmRlbmNpZXMgb24gMyBuZXcgUlBNcy48L3NwYW4+PGJyPjxzcGFuPjwv
c3Bhbj48YnI+PHNwYW4+T3B0aW9uYWw6PC9zcGFuPjxicj48c3Bhbj4tIFRoZXNlIHRocmVlIHRv
b2xzIHNoYXJlIHNvbWUgcHl0aG9uIGNsYXNzZXMgdGhhdCBhcmUgdmVyeSBzaW1pbGFyLiAmbmJz
cDtJIHdvdWxkIGxpa2UgdG8gY3JlYXRlIGEgR0lUIHJlcG8gKHBlcmhhcHMgb3ZpcnQtdG9vbHMt
Y29tbW9uKSB0byBjb250YWluIHRoZXNlIGNsYXNzZXMgc28gdGhhdCBhIGZpeCBpbiBvbmUgcGxh
Y2Ugd2lsbCBmaXggdGhlIGlzc3VlIGV2ZXJ5d2hlcmUuICZuYnNwO1BlcmhhcHMgd2UgY2FuIGFs
c28gY3JlYXRlIGEgbmFrZWQgR0lUIHJlcG8gZm9yIHRoZXNlIGNvbW1vbiBjbGFzc2VzIHdoaWxl
IGFkZHJlc3NpbmcgdGhlIHByaW1hcnkgY29uY2VybnMgYWJvdmUuPC9zcGFuPjxicj48L2Rpdj48
L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj4rMSBvbiB0aGUgZW50aXJlIHN1Z2dlc3Rp
b24uPC9kaXY+PGRpdj5hYm91dCB0aGUgY29tbW9uIHN0dWZmLSB3aWxsIHRoaXMgcGFja2FnZSBi
ZSBvYnNvbGV0ZSBvbmNlIHRoZSB0b29scyB3aWxsIGJlIGJhc2Ugb24gdGhlIHNkaz88L2Rpdj48
YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPlBs
ZWFzZSBjb21tZW50LDwvc3Bhbj48YnI+PHNwYW4+S2VpdGggUm9iZXJ0c29uPC9zcGFuPjxicj48
c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bh
bj48YnI+PHNwYW4+RW5naW5lLWRldmVsIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+PHNwYW4+PGEg
aHJlZj0ibWFpbHRvOkVuZ2luZS1kZXZlbEBvdmlydC5vcmciPkVuZ2luZS1kZXZlbEBvdmlydC5v
cmc8L2E+PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJodHRwOi8vbGlzdHMub3ZpcnQub3JnL21h
aWxtYW4vbGlzdGluZm8vZW5naW5lLWRldmVsIj5odHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxt
YW4vbGlzdGluZm8vZW5naW5lLWRldmVsPC9hPjwvc3Bhbj48YnI+PC9kaXY+PC9ibG9ja3F1b3Rl
PjwvYm9keT48L2h0bWw+
--Apple-Mail-7402373A-C19A-4425-B89A-E12094770920--
7:43 a.m.
This is a multi-part message in MIME format.
--------------000804070007050707040803
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 02/11/2012 03:48 AM, Ofer Schreiber wrote:
On 10 Feb 2012, at 16:42, Keith Robertson <kroberts(a)redhat.com
<mailto:kroberts@redhat.com>> 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 <http://oVirt.org> for
> the 3 tools.
> Step 2: Link git repos to gerrit.
> 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.
+1 on the entire suggestion.
about the common stuff- will this package be obsolete once the tools
will be base on the sdk?
No. The SDK is different it provides a common mechanism
for accessing
the REST API. Whereas, the common tools repo is more geared to the
tooling (e.g. common classes for logging, option parsing, etc.). It
would look like this...
[Common Tools] [REST SDK]
\ /
[image-uploader, iso-uploader, log-collector]
Cheers,
Keith
>
> Please comment,
> Keith Robertson
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org <mailto:Engine-devel@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/engine-devel
--------------000804070007050707040803
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 02/11/2012 03:48 AM, Ofer Schreiber wrote:
<blockquote
cite="mid:8FF5A0E4-AE69-4F19-87A9-2BEEE70DD78D@redhat.com"
type="cite">
<div>
<div style="text-align: left; direction: ltr;"><br>
</div>
</div>
<div>On 10 Feb 2012, at 16:42, Keith Robertson <<a
moz-do-not-send="true"
href="mailto:kroberts@redhat.com">kroberts@redhat.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div><span>All,</span><br>
<span></span><br>
<span>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.</span><br>
<span></span><br>
<span>The Plan:</span><br>
<span>Step 1: Create naked GIT repos on <a
moz-do-not-send="true"
href="http://oVirt.org">oVirt.org</a>
for the 3 tools.</span><br>
<span>Step 2: Link git repos to gerrit.</span><br>
<span>Step 3: Populate naked GIT repos with source and build
standalone spec files for each.</span><br>
<span>Step 4: In one patch do both a) and b)...</span><br>
<span> a) Update oVirt manager GIT repo by removing tool
source.</span><br>
<span> b) Update oVirt manager GIT repo such that spec has
dependencies on 3 new RPMs.</span><br>
<span></span><br>
<span>Optional:</span><br>
<span>- 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.</span><br>
</div>
</blockquote>
<div><br>
</div>
<div>+1 on the entire suggestion.</div>
<div>about the common stuff- will this package be obsolete once
the tools will be base on the sdk?</div>
</blockquote>
No. The SDK is different it provides a common mechanism for
accessing the REST API. Whereas, the common tools repo is more
geared to the tooling (e.g. common classes for logging, option
parsing, etc.). It would look like this...<br>
<br>
[Common Tools] [REST SDK]<br>
\ /<br>
[image-uploader, iso-uploader, log-collector]<br>
<br>
<br>
Cheers,<br>
Keith<br>
<blockquote
cite="mid:8FF5A0E4-AE69-4F19-87A9-2BEEE70DD78D@redhat.com"
type="cite"><br>
<blockquote type="cite">
<div><span></span><br>
<span>Please comment,</span><br>
<span>Keith Robertson</span><br>
<span>_______________________________________________</span><br>
<span>Engine-devel mailing list</span><br>
<span><a moz-do-not-send="true"
href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a></span><br>
<span><a moz-do-not-send="true"
href="http://lists.ovirt.org/mailman/listinfo/engine-devel">...
</div>
</blockquote>
</blockquote>
<br>
</body>
</html>
--------------000804070007050707040803--
7:44 a.m.
On 02/10/2012 02:33 PM, Paulo de Rezende Pinatti wrote:
Hi,
a suggestion for the plan: you could use git filter-branch with the
--subdirectory-filter option for creating the repos at step 1. That
way it will keep commit history of the files being moved in the new
repos.
No argument from me here. I'd like to keep my history.
Paulo de Rezende Pinatti
Staff Software Engineer
IBM Linux Technology Center
On 02/10/2012 12: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.
> 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.
>
> Please comment,
> Keith Robertson
> _______________________________________________
> Arch mailing list
> Arch(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>
4:41 p.m.
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.
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?
4:44 p.m.
On 02/12/2012 12:41 AM, Itamar Heim wrote:
> 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.
> 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.
Also, run at list pylint jobs tracking changes to these new repos (cc'd
eedri to coordinate with)
2:26 a.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Keith Robertson" <kroberts(a)redhat.com>
Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org, "Eyal Edri"
<eedri(a)redhat.com>
Sent: Sunday, February 12, 2012 12:44:40 AM
Subject: Re: [Engine-devel] New oVirt GIT Repo Request
On 02/12/2012 12:41 AM, Itamar Heim wrote:
>> 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.
>
>> 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.
Also, run at list pylint jobs tracking changes to these new repos
(cc'd
eedri to coordinate with)
It shouldn't be a problem if we want to test python code (pyflakes/pylint) via gerrit
& jenkins.
(we might want to use -E just for errors, otherwise we'll get a lot of warnings we
can't handle).
testing java (+maven) code will require moving to maven 3.0.X due to jenkins plugins
backward compatible issues.
Eyal.
7:32 a.m.
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.
Perhaps:
common/src/<python>
common/src/<java>/com/ovirt/whatever
6:31 a.m.
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.
Perhaps:
common/src/<python>
common/src/<java>/com/ovirt/whatever
_______________________________________________
Arch mailing list
Arch(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/arch
7:20 a.m.
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
9:57 a.m.
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.
--
Cheers
Douglas
9:09 a.m.
On 02/13/2012 03:20 PM, Keith Robertson wrote:
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.
The following repo's were created:
ovirt-image-uploader
ovirt-iso-uploader
ovirt-log-collector
ovirt-tools-common-python
I've used the existing ovirt-engine-tools group for its maintainers, as
this is only a split of part of the tools from using the engine git, but
tools project was defined as separate wrt maintainers.
4454
days inactive
4461
days old
12 comments
7 participants
participants (7)
-
Barak Azulay -
Douglas Landgraf -
Eyal Edri -
Itamar Heim -
Keith Robertson -
Ofer Schreiber -
Paulo de Rezende Pinatti