On 01/09/2015 03:22 PM, Sandro Bonazzola wrote:

Il 09/01/2015 15:13, Juan Hernández ha scritto:

...

Hello,

Please create the following new git repositories:

ovirt-engine-sdk-python-specs ovirt-engine-sdk-java-specs ovirt-engine-cli-specs

They will be used to manage the RPM spec files (also scripts, patches, and in general anything needed for building RPMs) of the Python SDK, the Java SDK, and the CLI. Each repository will have branches for each pair of oVirt major release and supported distribution:

Any reason for not having something like "ovirt-specs" with suggested branches:

...

ovirt-3.5-el6 ovirt-3.5-el7 ovirt-3.5-fc20 ovirt-3.5-fc21 ovirt-3.6-el6 ...

and having there

ovirt-engine-sdk-python/ovirt-engine-sdk-python.spec ovirt-engine-sdk-python/0001-your-friendly-patch.patch ovirt-engine-sdk-java/ovirt-engine-sdk-java.spec ovirt-engine-cli/ovirt-engine-cli.spec ...

I don't have any objection to that, as long as we can have the above mentioned branches and commit permissions.

...

Initially I will be the maintainer of these repositories.

Once these repos are created the specs will be added to them and eventually removed completely from the main repositories of the SDKs and the CLI.

Thanks in advance, Juan Hernández

-- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.

I really discourage having separated repos for specs, scripts or any 'code' used for building any official packages. That complicates (to the point of making it not feasible) a continuous build approach, and introduces a lot of complexity and limitations to the continuous integration of the project. If we can avoid it, I really discourage it. Can we talk about it and find a more friendly solution? David Caro On Jan 9, 2015 4:27 PM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:

Il 09/01/2015 15:13, Juan Hernández ha scritto:

...

Hello,

Please create the following new git repIl 09/01/2015 15:13, Juan Hernández ha scritto: Hello,

Please create the following new git repositories:

ovirt-engine-sdk-python-specs ovirt-engine-sdk-java-specs ovirt-engine-cli-specs

They will be used to manage the RPM spec files (also scripts, patches, and in general anything needed for building RPMs) of the Python SDK, the Java SDK, and the CLI. Each repository will have branches for each pair of oVirt major release and supported distribution:

Any reason for not having something like "ovirt-specs" with suggested branches:

ovirt-3.5-el6 ovirt-3.5-el7 ovirt-3.5-fc20 ovirt-3.5-fc21 ovirt-3.6-el6 ...

and having there ovirt-engine-sdk-python/ovirt-engine-sdk-python.spec ovirt-engine-sdk-python/0001-your-friendly-patch.patch ovirt-engine-sdk-java/ovirt-engine-sdk-java.spec ovirt-engine-cli/ovirt-engine-cli.spec ...

Initially I will be the maintainer of these repositories.

Once these repos are created the specs will be added to them and eventually removed completely from the main repositories of the SDKs and the CLI.

Thanks in advance, Juan Hernández

-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

--82I3+IH0IqGh5yIs Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 01/12, Sandro Bonazzola wrote:

Il 09/01/2015 23:48, David Caro Estevez ha scritto:

...

I really discourage having separated repos for specs, scripts or any 'c= ode' used for building any official packages. =20 That complicates (to the point of making it not feasible) a continuous = build approach, and introduces a lot of complexity and limitations to the c= ontinuous integration of the project. =20 I'm not realy sure to follow. What's the difference between Juan's reques= t and what we have already in place for jasper-report-server or ovirt-engine-jboss-as? We have specs and sources in different locations t= here too.

The difference is that we control the source code, we are not doing any continuous integration of those projects, as we don't control the source reposiotries, if we did, it would be complicated to manage as it's split in two repos (one for the code and another for the specs). That makes it really hard to create a continuous deployment pipeline as you have to keep track for each source code commit, which commit of the spec file is the one that can build it. And we don't do that, so we can't build any point in th esource code, once a non-backwards compatible change is made to the spec all the previous code becomes obsolete. It also affects to the ability to keep a semantic versioning of the product, as you'll have to manage generating a version from multiple repositories (and keep the version<->hashes map and the ordering). As a change on the spec should be reflected on the version of the generated package.

=20

...

=20 If we can avoid it, I really discourage it. Can we talk about it and fi= nd a more friendly solution? =20 I've no strong feelings for existing or proposed solution. I just think that from a packaging for distribution point of view, the ko= ji way of separating specs and sources is fine. =20

The problem is in the continuos integration and build point of view. If you are not aiming to build countinuously it does not matte.

...

=20 David Caro =20 On Jan 9, 2015 4:27 PM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:

...

Il 09/01/2015 15:13, Juan Hern=E1ndez ha scritto:

...

Hello,

Please create the following new git repIl 09/01/2015 15:13, Juan Hern=

=E1ndez ha scritto:

...

Hello,

Please create the following new git repositories:

ovirt-engine-sdk-python-specs ovirt-engine-sdk-java-specs ovirt-engine-cli-specs

They will be used to manage the RPM spec files (also scripts, patches, and in general anything needed for building RPMs) of the Python SDK, t= he Java SDK, and the CLI. Each repository will have branches for each pair of oVirt major release and supported distribution:

=20 Any reason for not having something like "ovirt-specs" with suggested branches: =20 =20

...

ovirt-3.5-el6 ovirt-3.5-el7 ovirt-3.5-fc20 ovirt-3.5-fc21 ovirt-3.6-el6 ... =20 =20 and having there =20 ovirt-engine-sdk-python/ovirt-engine-sdk-python.spec ovirt-engine-sdk-python/0001-your-friendly-patch.patch ovirt-engine-sdk-java/ovirt-engine-sdk-java.spec ovirt-engine-cli/ovirt-engine-cli.spec ... =20

Initially I will be the maintainer of these repositories.

Once these repos are created the specs will be added to them and eventually removed completely from the main repositories of the SDKs a= nd the CLI.

Thanks in advance, Juan Hern=E1ndez

=20 =20 =20 =20 --=20 Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

--=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUs4DFAAoJEEBxx+HSYmnDjLsH/3UtWBx6krCiX8g8PXhWrI+V 3T0kgRBLUhOZcrAWJDLey8aB798bjc65G+pY6b2u2GyS8CU8jT8KRJ8Rrtlofd6H z5gmo7G5uCiE7VG5JpMnkgb2vJUZ+ps+xL6cdzAUld8P8tGY8mt8Fd/QXhvGsAXL y3qtYWhfvecl3Fbl+C0TOir/VNqhPWFNGrF4c8EAH9NC4blsMjojUQOc9ID+t7At kpgDSAfkBFDc27IIpIvYYsWh9DUCtQTBqYJgVN9ttzVAHacH7W2Ag8bh/jX3xhNx 7ySH0LDb7cYJlxYFHYvj4yuz2rP+WjqbDv3HYjQ42OVNucqAk5aFgB3IK+nYKqQ= =Pxc6 -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs--