=20 =20 ----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com>, "infra" <infra@ovirt.org> Sent: Monday, May 5, 2014 7:10:31 PM Subject: Re: Package building and build process
On 05/05/2014 05:51 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "infra" <infra@ovirt.org> Sent: Monday, May 5, 2014 6:39:53 PM Subject: Package building and build process
Hi!
Lately we had some issues when trying to build some of the projects,=
and
we wanted to start a discussion to clarify what do we want and how to g= et there.
We can split the thread if it gets too large for all the subjects.
The main points to discuss:
* How the source tarballs should be built =C2=B7 Should we use a jenkins job for it, so the maintainer just = downloads the tarball from it =C2=B7 Should we force the maintainer to build it and supply the t= arball himself =C2=B7 Should we allow both
Not sure why you manage this discussion. You just forgot to mention that up until now it worked perfectly ok, = we had a job to build releases out of tarballs, and all worked perfectly. It was broken when you decided not to install certain dependencies on= build slaves.
Arising from different version of some projects requiring different ve= rsion of different packages and different test requiring different sources for =
same packages (testing against nightly, stable, pep8 latest, pep8 epel, ...= ) we had to introduce some job isolation, and reserving one slave for each job =
running became unproductive and hard to maintain (at first, we had som= e slaves for each project, then started installing and removing packages on eac= h job, then not only installing and removing packages but also repositories, isolating the build on the same slave became a necessity).
Anyway...
This is up to maintainer to decide.
It's up to the CI/infra/release team to provide the platform to build =
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oOWjjvxotEwtajEGIaiDpMrF0lf0pFnKH Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/05/2014 06:26 PM, Alon Bar-Lev wrote: the that is the
projects for the maintainers to use. =20 As a service to the group.
Yes, as a service to the group and ultimately to the project I'm part of = the people that decides how to manage and provide that infrastructure.
=20
Build infrastructure should be able to get upstream tarball (any upst=
ream
not just ovirt) and produce binaries for all our supported platforms = as a service, just like koji, brew or any downstream service. The root resource of open source is the source tarball, this is the r= elease not the binary. That's what the next point is about.
People here at ovirt tend to confuse what open source is.
* Separate source release from binary release
* Which tools to use to build the rpms =C2=B7 plain rpmbuild =C2=B7 Mock =C2=B7 Docker =C2=B7 copr =C2=B7 Open Build System =C2=B7 koji
Once upstream releases source tarball, this is not important. This is the entire idea of open *SOURCE*. It might not be important to you, but we want to provide the easiest w= ay for the users to use oVirt, not only for someone to build it, having a binary = release for the major platforms helps TREMENDOUSLY on getting users to use the=
product. =20 Once again... and again... and again.... =20 The release is the source tarball. I already acked this.
We provide the service of providing binaries as well. This is fine, this is a service. =20
* How to organize the rpm/tar build jobs =C2=B7 One job for all the projects =C2=B7 One job per-project
If we cannot provide single job for generic tarball build, we have a =
problem. I don't agree. =20 You do not need to agree, you should provide it as a service. Yes, I need to agree, as I've been appointed by the group as part of the decision making process that has responsibility over that service, you ar= e not. And as such you haven't earned the right to tell anyone in this team what=
huge they should and what they should not do, you are welcome to share your opinion= , but don't expect anyone to follow your orders.
=20
I worked very hard with all maintainers (except vdsm) to be able to a=
chieve
the standard sequence of:
# rpmbuild -tb <tarball>
You are not taking into account all the dependencies that rpmbuild -tb=
<tarball> has, each project has it's own, and they are incompatible between proj= ects and between versions. And not just building the rpms, building the tarball= s also have some requirements that must be met. So building a package is not = just rpmbuild, but setup the repos, install packages, then rpmbuild, then c= leanup packages and restore repos. =20 rpmbuild -ts <tarball> yum-builddep <srpm> =20 solves this as well, adding optional repositories can be a parameter to= the job.
I did not say that it was not doable, only that we might want to replicat= e it per-project for the sake of organization and easy management.
=20 all was already done nothing to reinvent. =20
Regards, Alon Bar-Lev.
PD. Opened an etherpad to keep the points http://etherpad.ovirt.org/p/build_discussion -- David Caro
Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D
Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- David Caro
Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D
Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605
--=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --oOWjjvxotEwtajEGIaiDpMrF0lf0pFnKH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTZ8FiAAoJEEBxx+HSYmnDDx0H/R5S17q2YSZ9bbggjHwM08vt wu4m5dE+05dGOyWV5ZQP+M4xGey3LAf85j2KXelOhqKPYDUZClYMuyiEbywG1cw1 GQzUXNVCC8UY9ZryGND/84r8wp+6L5x7Fhyodc/7sr1QKtlxo3aBmYTss7pQX9q7 So9prfjdHaMAhHt9MqaOx4y/KzGFJbUYb9S/EiCaW4OXvwpIEwrLgzwALha8aUCd vTHWItQSU+8foCEDz1RPwQ34++CxwnbXC7ccpDY59OJ3fiz43Hia9xV2gBR+B7jE DJN9TpuGAMaXC5bpa0abanFxC8FCG6nI7j00rsTHz+ikh+rnEeMrbzgyEpxReNQ= =7PVQ -----END PGP SIGNATURE----- --oOWjjvxotEwtajEGIaiDpMrF0lf0pFnKH--