[Engine-devel] New oVirt GIT Repo Request
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
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch
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=
=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=
--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@redhat.com> wrote: the ovirt-log-collector, ovirt-iso-uploader, and ovirt-image-uploader each i= nto their own GIT repos. 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@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--
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@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@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">http://lists.ovirt.org/mailman/listinfo/engine-devel</a></span><br> </div> </blockquote> </blockquote> <br> </body> </html> --------------000804070007050707040803--
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?
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)
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Keith Robertson" <kroberts@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org, "Eyal Edri" <eedri@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.
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
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch
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
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
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.
participants (7)
-
Barak Azulay -
Douglas Landgraf -
Eyal Edri -
Itamar Heim -
Keith Robertson -
Ofer Schreiber -
Paulo de Rezende Pinatti