6:10 p.m.
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Ut5KeQuHDK9anwIkd85SuJEOGNdVSwa9b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 05/05/2014 05:51 PM, Alon Bar-Lev wrote:
=20
=20
----- Original Message -----
> From: "David Caro" <dcaroest(a)redhat.com>
> To: "infra" <infra(a)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, a=
nd we
> wanted to start a discussion to clarify what do we want and how
to get=
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 do=
wnloads
the
> tarball from it
> =C2=B7 Should we force the maintainer to build it and supply the tar=
ball
himself
> =C2=B7 Should we allow both
=20
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
b=
uild slaves.
Arising from different version of some projects requiring different versi=
on of
different packages and different test requiring different sources for the=
same
packages (testing against nightly, stable, pep8 latest, pep8 epel, ...) w=
e had
to introduce some job isolation, and reserving one slave for each job tha=
t is
running became unproductive and hard to maintain (at first, we had some s=
laves
for each project, then started installing and removing packages on each j=
ob,
then not only installing and removing packages but also repositories, iso=
lating
the build on the same slave became a necessity).
=20
Anyway...
=20
This is up to maintainer to decide.
It's up to the CI/infra/release team to provide the platform to build the=
projects for the maintainers to use.
Build infrastructure should be able to get upstream tarball (any
upstre=
am not just ovirt) and produce binaries for all our supported platforms a=
s a service, just like koji, brew or any downstream service.
The root resource of open source is the source tarball, this is the
rel=
ease not the binary.
That's what the next point is about.
People here at ovirt tend to confuse what open source is.
=20
>
> * 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
=20
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 way =
for the
users to use oVirt, not only for someone to build it, having a binary rel=
ease
for the major platforms helps TREMENDOUSLY on getting users to use the pr=
oduct.
=20
> * How to organize the rpm/tar build jobs
> =C2=B7 One job for all the projects
> =C2=B7 One job per-project
=20
If we cannot provide single job for generic tarball build, we have a hu=
ge
problem.
I don't agree.
=20
I worked very hard with all maintainers (except vdsm) to be able to ach=
ieve the
standard sequence of:
=20
# rpmbuild -tb <tarball>
You are not taking into account all the dependencies that rpmbuild -tb <t=
arball>
has, each project has it's own, and they are incompatible between project=
s and
between versions. And not just building the rpms, building the tarballs a=
lso
have some requirements that must be met. So building a package is not jus=
t
rpmbuild, but setup the repos, install packages, then rpmbuild, then clea=
nup
packages and restore repos.
=20
Regards,
Alon Bar-Lev.
=20
>
> 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(a)redhat.com
> Web: www.redhat.com
> RHT Global #: 82-62605
>
>
> _______________________________________________
> Infra mailing list
> Infra(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
--=20
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Email: dcaro(a)redhat.com
Web: www.redhat.com
RHT Global #: 82-62605
--Ut5KeQuHDK9anwIkd85SuJEOGNdVSwa9b
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
iQEcBAEBAgAGBQJTZ7f3AAoJEEBxx+HSYmnDku8H/0fsG5LEkLYCc8X0j/XPWW/u
X7rdoZuuLGaXjs966YmeM1sQD3VjtAg35qo1EXr/GdQesft0Ysn8zAzohjkrf+YH
A/iX+QzC/N1M5mGYWgKTxCDDIdsxraQiLAQ14ykDhzAniF8UdGnmrRTdmUxBCbyh
kZi7yMeD79iEJR1YoZY5oFY6CsBAdfeyZW6z3Gj7+deDhgOh9AtrsYVKvdvDmQVy
81WwAW5PWuMFPS1NuM7KrToaoiq1bsLO0Yj/8QdPJaaJ3BoybESchKsUr8f6SMXi
jaKVXzX6axvZIqD4W+RKa1VPzGSj78edxjUlxvJITJz4j8OHL91l5GG11O1ztyU=
=JVm7
-----END PGP SIGNATURE-----
--Ut5KeQuHDK9anwIkd85SuJEOGNdVSwa9b--