6:50 p.m.
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:
=20
=20
----- Original Message -----
> From: "David Caro" <dcaroest(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>, "infra"
<infra(a)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(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,=
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 =
the
> same
> packages (testing against nightly, stable, pep8 latest, pep8 epel, ...=
) we
> had
> to introduce some job isolation, and reserving one slave for each job =
that
is
> 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 =
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 =
huge
>> 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=
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(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
>>>
>
>
> --
> 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
>
>
--=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
--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--