[CentOS-devel] planning and coordination with EPEL

Lalatendu Mohanty

lmohanty at redhat.com
Wed Sep 24 12:05:51 UTC 2014


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




More information about the CentOS-devel mailing list