So, for the short term(relatively speaking), it seems that CentOS contributors wishing to push packages into EPEL would need to follow epel policy[1] for getting their packages pushed.
For some this is fine, as they're already contributing. For others, this is a duplicated workload with added stress.
I'd like to propose that we form a group of CentOS participants who are fedora/EPEL packagers to curate packages marked for sharing.
SIGs who have common packages to be shared would then be able to request that this group of curators submit the package via existing EPEL processes. This process assumes a couple things:
1. curators have access to modify the package in both systems (to correct things in spec files for example)
2. We adopt the fedora/EPEL packaging guidelines as much as possible to minimize changes required by the curators group.
3. We have some method of assigning package ownership to SIGs and to the curators.
Longer-term, I think we'll be able to work something out with EPEL that's a bit less manual, but I think this process should work for now.
Comments, questions, suggested changes before I propose this to the EPEL folks as well?
[1] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
On Sep 23 10:20, Jim Perrin wrote:
So, for the short term(relatively speaking), it seems that CentOS contributors wishing to push packages into EPEL would need to follow epel policy[1] for getting their packages pushed.
For some this is fine, as they're already contributing. For others, this is a duplicated workload with added stress.
I'd like to propose that we form a group of CentOS participants who are fedora/EPEL packagers to curate packages marked for sharing.
SIGs who have common packages to be shared would then be able to request that this group of curators submit the package via existing EPEL processes. This process assumes a couple things:
- curators have access to modify the package in both systems (to
correct things in spec files for example)
- We adopt the fedora/EPEL packaging guidelines as much as possible to
minimize changes required by the curators group.
- We have some method of assigning package ownership to SIGs and to the
curators.
Longer-term, I think we'll be able to work something out with EPEL that's a bit less manual, but I think this process should work for now.
Comments, questions, suggested changes before I propose this to the EPEL folks as well?
[1] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
-- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
This seems like the most efficient process given current policies. Count me in for helping curate.
Brian
-- Brian Stinson bstinson@ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk
On 09/23/2014 08:50 PM, Jim Perrin wrote:
So, for the short term(relatively speaking), it seems that CentOS contributors wishing to push packages into EPEL would need to follow epel policy[1] for getting their packages pushed.
For some this is fine, as they're already contributing. For others, this is a duplicated workload with added stress.
What about SIGs using packages from EPEL (to resolve dependency) but they lack skills to maintain those packages. Will EPEL folks will also contribute back to CentOS eco-system?
I'd like to propose that we form a group of CentOS participants who are fedora/EPEL packagers to curate packages marked for sharing.
SIGs who have common packages to be shared would then be able to request that this group of curators submit the package via existing EPEL processes. This process assumes a couple things:
- curators have access to modify the package in both systems (to
correct things in spec files for example)
- We adopt the fedora/EPEL packaging guidelines as much as possible to
minimize changes required by the curators group.
- We have some method of assigning package ownership to SIGs and to the
curators.
Longer-term, I think we'll be able to work something out with EPEL that's a bit less manual, but I think this process should work for now.
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.
Comments, questions, suggested changes before I propose this to the EPEL folks as well?
[1] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
Thanks, Lala
On 09/23/2014 03:54 PM, Lalatendu Mohanty wrote:
On 09/23/2014 08:50 PM, Jim Perrin wrote:
So, for the short term(relatively speaking), it seems that CentOS contributors wishing to push packages into EPEL would need to follow epel policy[1] for getting their packages pushed.
For some this is fine, as they're already contributing. For others, this is a duplicated workload with added stress.
What about SIGs using packages from EPEL (to resolve dependency) but they lack skills to maintain those packages. Will EPEL folks will also contribute back to CentOS eco-system?
You could argue that EPEL is already contributing simply by delivering the current repositories.
I haven't brought this proposal to EPEL yet, as I want to make sure everyone (or at least the majority) is okay with this from our side. The existing EPEL policies for bug reporting and bug fixes are likely to remain, so if you're using them now, you'll be no worse off in the future than you presently are.
Longer-term, I think we'll be able to work something out with EPEL that's a bit less manual, but I think this process should work for now.
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.
-----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.
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.
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@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Wed, Sep 24, 2014 at 3:31 AM, Thomas Oulevey thomas.oulevey@cern.ch 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.
EPEL is built into the published "mock" RPMS as a default repository. Why not, since the mock RPM itself is published from EPEL? It's actually extra work to *disable* EPEL, to avoid accidental dependencies
Unfortunately, this casual inclusion is somewhat unstable. Because EPEL does not keep old versions of its packages around, and because some components can migrate from EPEL publication to RHEL inclusion, you can wind up with components built against an older version in EPEL that is no longer available, and are now found in RHEL or CentOS. Worse, you can wind up with working older versions of EPEL components that no longer have their dependencies in an easily accessible public repository and are difficult to include for new deployments. That way lies madness.
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.
This.
I personally deal with it by keeping a nightly rsync of EPEL around, without using "--delete" and following up with relevant 'createrepo' commands, so old packages remain available on my internal EPEL mirror. But it's not completely reliable.
On Sep 23, 2014 10:28 AM, "Jim Perrin" jperrin@centos.org wrote:
So, for the short term(relatively speaking), it seems that CentOS contributors wishing to push packages into EPEL would need to follow epel policy[1] for getting their packages pushed.
For some this is fine, as they're already contributing. For others, this is a duplicated workload with added stress.
I'd like to propose that we form a group of CentOS participants who are fedora/EPEL packagers to curate packages marked for sharing.
SIGs who have common packages to be shared would then be able to request that this group of curators submit the package via existing EPEL processes. This process assumes a couple things:
- curators have access to modify the package in both systems (to
correct things in spec files for example)
- We adopt the fedora/EPEL packaging guidelines as much as possible to
minimize changes required by the curators group.
- We have some method of assigning package ownership to SIGs and to the
curators.
Longer-term, I think we'll be able to work something out with EPEL that's a bit less manual, but I think this process should work for now.
Comments, questions, suggested changes before I propose this to the EPEL folks as well?
+1 - I'd be interested in a task list when the time comes and would be happy to help where I am able.
-AdamM
[1] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
-- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-
Adam Miller -
Brian Stinson -
Jim Perrin -
Lalatendu Mohanty -
Nico Kadel-Garcia -
Thomas Oulevey