On 09/24/2014 01:01 PM, Thomas Oulevey wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > On 09/24/2014 01:13 AM, Jim Perrin wrote: > >>> Do you mean, we will directly consume EPEL (if required) in SIGs? >>> As of now we add required packages from EPEL to the build root >>> manually. >> >> This would be something for the people running the build system to >> answer. Currently epel-release is available, but it's a two step >> process. First yum install epel-release, *then* install whatever >> deps you need. I'm not certain if this can be managed for a >> particular build target within koji, so I'll defer to someone else >> to answer. >> > EPEL can be configured as an external repository > (https://fedoraproject.org/wiki/Koji/ExternalRepoServerBootstrap) and > so packages are directly available in the buildroot. > > The idea is to have a clear workflow for SIG: > > 1/ Let's say a SIG have been approved. > 2/ sig-admins are defined (members of the board) > 3/ sig-admins request for a buildsystem target and workflow ( [build > - -> testing -> release] at this point but can evolve according to needs). > At this time we ask a ticket with the following information : > - Short name (virt, cloud, storage, let's try to keep it simple) > - What distribution they want to build against (5,6,7) > - What external repositories they depend on (epel, rdo, whatever > yum repo) > > Not only relevant to EPEL, but in my opinion it should be a SIG > decision (Core SIG may keep an eye on repo reputation and approve them > in koji. i.e security concern) on what external repositories (and > associated risks) they are ready to support. This work-flow is nice. I am fine with it. If no-one has any issue with it, we can put this some where in the wiki for SIGs reference. > At work, we build against EPEL in Koji for the last 2 years and we > never experience any issue. They only important parameter to remember > is the package retention policy (only last version is kept in EPEL > stable repo, no yum downgrade, etc...) so you need to keep a eye on > their process. > > - -- > Thomas. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > > iQEcBAEBAgAGBQJUInNEAAoJEH2Wn86OP8NiSLkH/inKh92VDfqlQUsTBbEWHm6V > viDqtyHm/+7Uveg7luDORlL51WkJyVAoUkrA4jZPYPrmplXjXjLp6p1VFFUUx7Zi > oITQwdnuIkLJpzFULYAYmcYJpgNSJO47nQWzi1aNwJ3aRjw3IkOEhjagB5WQIxwv > CcFJJ48wONlUhTorVQoYQUrnkjh1cCFyWqPGZROKWusfvjpPEa4aGDWZwMiWrrHl > RhUmwVa44r/wnrRqFz2vCNz6mx1FzAIB4So7sFQKkrp4xOOoX8pBmIN4l6f+dApI > 7zeJRZEvJZtJtc17AhHSYcSIhtUGnQW2U6reCT/9nXjOE0nnlaRbZq+lidPZ6ho= > =7vgQ > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel