Il 09/01/2015 23:48, David Caro Estevez ha scritto:
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.
I'm not realy sure to follow. What's the difference between Juan's request and what we have already in place for jasper-report-server or ovirt-engine-jboss-as? We have specs and sources in different locations there too.
If we can avoid it, I really discourage it. Can we talk about it and find a more friendly solution?
I've no strong feelings for existing or proposed solution. I just think that from a packaging for distribution point of view, the koji way of separating specs and sources is fine.
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