Hi,
Since the CentOS acquihire, there was a lot of discussion about EPEL's future. Since the FOSDEM meetup between Fedora/CentOS folks, there was little progress on that topic
After a discussion with a Smooge, I decided to come with a proposal, knowing that 1. Fedora wants to keep EPEL within it umbrella 2. That CentOS SIGs are in practice rebuilding a lot of EPEL packages (or retag them for other SIGs) leading to poor maintenance as they don't follow EPEL tickets for all their dependencies. 3. EPEL is not part CentOS plans, and as soon as SIGs will progress, *may* turn the former irrelevant 4. Some EPEL packages are poorly maintained especially on older EL releases and/or orphaned
We've reached the point where both EPEL/CBS would greatly benefit to join hands.
So I suggest that we consider the following: * EPEL will still use Fedora dist-git * EPEL builds should be done in CBS to make it easier for SIGs to consume it. * EPEL will use CentOS repositories instead of mirroring RHEL repositories * Bridging Fedora/CentOS accounting system (CentOS is migrating to FAS) <== we need to see the feasibility of this but that would be optimal, that would increase the permeability between our two contributors pools which is something, we all want to encourage. * Create a EPEL provenpackager group under CentOS core SIG supervision, allowing them to appoint people to maintain EPEL packages.
I suggest that we keep the EPEL name to acknowledge EPEL historical effort to provide quality additional packages for EL distros. Fedora contributors would still be able to contribute to EPEL, and CentOS contributors to make it up their standards.
Would that work for you?
Regards, H.
On Mon, Sep 21, 2015 at 7:12 AM, Haïkel hguemar@fedoraproject.org wrote:
Hi,
Since the CentOS acquihire, there was a lot of discussion about EPEL's future. Since the FOSDEM meetup between Fedora/CentOS folks, there was little progress on that topic
After a discussion with a Smooge, I decided to come with a proposal, knowing that
- Fedora wants to keep EPEL within it umbrella
- That CentOS SIGs are in practice rebuilding a lot of EPEL packages
(or retag them for other SIGs) leading to poor maintenance as they don't follow EPEL tickets for all their dependencies. 3. EPEL is not part CentOS plans, and as soon as SIGs will progress, *may* turn the former irrelevant 4. Some EPEL packages are poorly maintained especially on older EL releases and/or orphaned
We've reached the point where both EPEL/CBS would greatly benefit to join hands.
So I suggest that we consider the following:
- EPEL will still use Fedora dist-git
- EPEL builds should be done in CBS to make it easier for SIGs to consume
it.
- EPEL will use CentOS repositories instead of mirroring RHEL repositories
- Bridging Fedora/CentOS accounting system (CentOS is migrating to
FAS) <== we need to see the feasibility of this but that would be optimal, that would increase the permeability between our two contributors pools which is something, we all want to encourage.
- Create a EPEL provenpackager group under CentOS core SIG
supervision, allowing them to appoint people to maintain EPEL packages.
I suggest that we keep the EPEL name to acknowledge EPEL historical effort to provide quality additional packages for EL distros. Fedora contributors would still be able to contribute to EPEL, and CentOS contributors to make it up their standards.
Would that work for you?
I'm a maintainer of several EPEL packages and a CentOS user. After reading through this, I don't understand the value in this shift. Also, what are the potential negatives of the change? Thanks, Dave
2015-09-21 16:38 GMT+02:00 Dave Johansen davejohansen@gmail.com:
I'm a maintainer of several EPEL packages and a CentOS user. After reading through this, I don't understand the value in this shift. Also, what are the potential negatives of the change? Thanks, Dave
I don't see any negative except that it will require some efforts to do the transition (and I'm already volunteering to work on that). Bridging two FAS instances may not be possible currently. The value is that, what CentOS SIGs are trying to build will leverage EPEL without having them duplicate in a poorly fashion, work done in EPEL. https://wiki.centos.org/SpecialInterestGroup Enhancing collaboration between EPEL and CentOS will allow us to ship a much better curated EPEL repository, you're more likely to find people able to provide proper maintenance of EPEL packages within the CentOS community.
And if CentOS ended up rebuilding an EPEL-like repositories (which will happen sooner or later), what will happen to EPEL? Moreover, rebuilding EPEL from scratch will be painful and long process.
Regards, H.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/21/2015 07:12 AM, Haïkel wrote:
- EPEL will use CentOS repositories instead of mirroring RHEL
repositories
Worth noting that one of the values people get (or perceive) about EPEL is that it is built against RHEL repositories. This is really important for people who use EPEL on RHEL, as it makes potential support discussions more clean. Red Hat's support team is more comfortable pointing customers at EPEL solutions knowing that it is build against RHEL rather than CentOS.
- - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
On Mon, 21 Sep 2015 16:12:07 +0200 Haïkel hguemar@fedoraproject.org wrote:
Hi,
Since the CentOS acquihire, there was a lot of discussion about EPEL's future. Since the FOSDEM meetup between Fedora/CentOS folks, there was little progress on that topic
After a discussion with a Smooge, I decided to come with a proposal, knowing that
- Fedora wants to keep EPEL within it umbrella
- That CentOS SIGs are in practice rebuilding a lot of EPEL packages
(or retag them for other SIGs) leading to poor maintenance as they don't follow EPEL tickets for all their dependencies.
Which tickets do you mean here? They are only rebuilding some packages, but not others or?
- EPEL is not part CentOS plans, and as soon as SIGs will progress,
*may* turn the former irrelevant
I suppose, but lots of people use/look to epel for packages, I don't think that will change to using packages from CentOS sigs overnight.
- Some EPEL packages are poorly maintained especially on older EL
releases and/or orphaned
Sure, just like any large collection of packages.
We've reached the point where both EPEL/CBS would greatly benefit to join hands.
So I suggest that we consider the following:
- EPEL will still use Fedora dist-git
- EPEL builds should be done in CBS to make it easier for SIGs to
consume it.
How do EPEL maintainers launch builds in CBS? How do builds get signed? How do updates get pushed out to EPEL users? Does CentOS have a bodhi instance?
- EPEL will use CentOS repositories instead of mirroring RHEL
repositories
CBS seems to not have ppc64... so no more ppc64 EPEL packages?
Also, this would probibly be some kind of big deal to some people who like that EPEL is built against rhel. Personally, I don't think it matters, but it would have to be communicated clearly.
- Bridging Fedora/CentOS accounting system (CentOS is migrating to
FAS) <== we need to see the feasibility of this but that would be optimal, that would increase the permeability between our two contributors pools which is something, we all want to encourage.
Bridging in which way? what information would be good to communicate back and forth?
- Create a EPEL provenpackager group under CentOS core SIG
supervision, allowing them to appoint people to maintain EPEL packages.
Overriding the existing EPEL maintainers?
I suggest that we keep the EPEL name to acknowledge EPEL historical effort to provide quality additional packages for EL distros. Fedora contributors would still be able to contribute to EPEL, and CentOS contributors to make it up their standards.
Would that work for you?
I think there would be a large amount of technical and public relations work needed to get anything like this off the ground.
If the problem is that CBS only has a subset of epel builds, perhaps we could solve that by setting up a script that listens to fedora fedmsgs and imports epel builds from fedora koji when they are done?
kevin
2015-09-21 19:46 GMT+02:00 Kevin Fenzi kevin@scrye.com:
On Mon, 21 Sep 2015 16:12:07 +0200 Haïkel hguemar@fedoraproject.org wrote:
Hi,
Since the CentOS acquihire, there was a lot of discussion about EPEL's future. Since the FOSDEM meetup between Fedora/CentOS folks, there was little progress on that topic
After a discussion with a Smooge, I decided to come with a proposal, knowing that
- Fedora wants to keep EPEL within it umbrella
- That CentOS SIGs are in practice rebuilding a lot of EPEL packages
(or retag them for other SIGs) leading to poor maintenance as they don't follow EPEL tickets for all their dependencies.
Which tickets do you mean here? They are only rebuilding some packages, but not others or?
Any tickets filed against EPEL, for instance, if a bug or CVE is fixed against EPEL package, CBS rebuilds won't be impacted as there's no way to automate that. Some examples from CentOS Cloud SIG: * RabbitMQ: it's a runtime requirement for OpenStack, we could just reuse EPEL packages but that would mean that Cloud SIG repository wouldn't be self-contained => Nick Coghlan's RepoFunnel would be a solution to mash repositories here. * A hell lot of python build requirements, that have to be rebuilt in CBS, as CBS don't have access to EPEL packages.
For instance, if the EPEL package gets fixed for a CVE, the CBS package may not get fixed (and vice-versa). Moreover, it makes mixing EPEL and CentOS SIGs repositories harder.
- EPEL is not part CentOS plans, and as soon as SIGs will progress,
*may* turn the former irrelevant
I suppose, but lots of people use/look to epel for packages, I don't think that will change to using packages from CentOS sigs overnight.
I agree.
- Some EPEL packages are poorly maintained especially on older EL
releases and/or orphaned
Sure, just like any large collection of packages.
Yes, but all the more a reason to make it easier for CentOS community to participate to this efforts
We've reached the point where both EPEL/CBS would greatly benefit to join hands.
So I suggest that we consider the following:
- EPEL will still use Fedora dist-git
- EPEL builds should be done in CBS to make it easier for SIGs to
consume it.
How do EPEL maintainers launch builds in CBS?
Through bstrinson centpkg tool as for the tooling aspect (infra-related issues are covered in a later point)
How do builds get signed?
That would be left to CentOS core SIG team
How do updates get pushed out to EPEL users? Does CentOS have a bodhi
Good question, from my current experience, I get little feedback on my EPEL updates and never got one pushed to stable just through karma.
instance?
- EPEL will use CentOS repositories instead of mirroring RHEL
repositories
CBS seems to not have ppc64... so no more ppc64 EPEL packages?
True, if we could get some stats over ppc64 (and any arch unsupported by CentOS), that would help weighting on the decision as for any trade-off.
Also, this would probibly be some kind of big deal to some people who like that EPEL is built against rhel. Personally, I don't think it matters, but it would have to be communicated clearly.
(I also saw Karsten reply about it) It needs to be communicated, but considering CentOS good history on that matter, I personally don't think it's big deal, too.
- Bridging Fedora/CentOS accounting system (CentOS is migrating to
FAS) <== we need to see the feasibility of this but that would be optimal, that would increase the permeability between our two contributors pools which is something, we all want to encourage.
Bridging in which way? what information would be good to communicate back and forth?
I'm not familiar enough with the FAS/pkgdb architecture, so I will just list some requirements. * ensure that EPEL packagers could rebuild their packages in CBS * ensure that CentOS core SIG could administrate epel-provenpackager group
Off course, it could be minimal and may not require syncing FAS instances, in the end.
- Create a EPEL provenpackager group under CentOS core SIG
supervision, allowing them to appoint people to maintain EPEL packages.
Overriding the existing EPEL maintainers?
Yes, as provenpackager could do with most Fedora packages but limited to EPEL branches. I know this may be difficult to give some control to another organization over part of our project. But we need to consider that Fedora/CentOS are part of a larger ecosystem.
I suggest that we keep the EPEL name to acknowledge EPEL historical effort to provide quality additional packages for EL distros. Fedora contributors would still be able to contribute to EPEL, and CentOS contributors to make it up their standards.
Would that work for you?
I think there would be a large amount of technical and public relations work needed to get anything like this off the ground.
If the problem is that CBS only has a subset of epel builds, perhaps we could solve that by setting up a script that listens to fedora fedmsgs and imports epel builds from fedora koji when they are done?
kevin
Yes, my first proposal may have sounded that it's trivial but it's not. On the other hand, this is something achievable and that could benefit for both projects.
As any proposal, this needs to be discussed, improved and comes with a lot of trade-offs but if nobody starts the discussion, we'll just go nowhere. All the points you raised are perfectly valid, and needs to be discussed with every stakeholder. Maybe the final solution will be completely different, but that's not what matters. This is a concrete way to build Fedora/CentOS collaboration.
If merging cost is too important, then we could discuss alternatives (like EPEL rebuilds automation in CBS), but we need to end the discussion at some point. Anyway, I won't champion any proposal that gets no support from both communities.
Regards, H.
On Mon, 21 Sep 2015 20:58:21 +0200 Haïkel hguemar@fedoraproject.org wrote:
2015-09-21 19:46 GMT+02:00 Kevin Fenzi kevin@scrye.com:
Which tickets do you mean here? They are only rebuilding some packages, but not others or?
Any tickets filed against EPEL, for instance, if a bug or CVE is fixed against EPEL package, CBS rebuilds won't be impacted as there's no way to automate that.
(well, if we imported from into CBS for EPEL builds there would be)
Some examples from CentOS Cloud SIG:
- RabbitMQ: it's a runtime requirement for OpenStack, we could just
reuse EPEL packages but that would mean that Cloud SIG repository wouldn't be self-contained => Nick Coghlan's RepoFunnel would be a solution to mash repositories here.
- A hell lot of python build requirements, that have to be rebuilt in
CBS, as CBS don't have access to EPEL packages.
For instance, if the EPEL package gets fixed for a CVE, the CBS package may not get fixed (and vice-versa). Moreover, it makes mixing EPEL and CentOS SIGs repositories harder.
Sure, having one place for a package makes sense, I just don't see why it can't be epel repos or koji?
...snip...
Yes, but all the more a reason to make it easier for CentOS community to participate to this efforts
Sure. I am all for helping get more participation...
...snip...
How do builds get signed?
That would be left to CentOS core SIG team
Well, it would have to be a new key, which I think some people may not like.
How do updates get pushed out to EPEL users? Does CentOS have a bodhi
Good question, from my current experience, I get little feedback on my EPEL updates and never got one pushed to stable just through karma.
Well, bodhi provides more than karma feedback. (BTW, hey look, a great place for people to participate!), but also handles things like drpms, multilib, updating bugs, etc.
...snipp...
Bridging in which way? what information would be good to communicate back and forth?
I'm not familiar enough with the FAS/pkgdb architecture, so I will just list some requirements.
- ensure that EPEL packagers could rebuild their packages in CBS
- ensure that CentOS core SIG could administrate epel-provenpackager
group
Off course, it could be minimal and may not require syncing FAS instances, in the end.
Yeah, I am not sure at all how such a bridging could work.
- Create a EPEL provenpackager group under CentOS core SIG
supervision, allowing them to appoint people to maintain EPEL packages.
Overriding the existing EPEL maintainers?
Yes, as provenpackager could do with most Fedora packages but limited to EPEL branches. I know this may be difficult to give some control to another organization over part of our project. But we need to consider that Fedora/CentOS are part of a larger ecosystem.
I've no objections to getting more people helping fix things, but I would think there would need to be a pretty clear process for adding people or removing them (if needed).
...snip...
If the problem is that CBS only has a subset of epel builds, perhaps we could solve that by setting up a script that listens to fedora fedmsgs and imports epel builds from fedora koji when they are done?
kevin
Yes, my first proposal may have sounded that it's trivial but it's not. On the other hand, this is something achievable and that could benefit for both projects.
As any proposal, this needs to be discussed, improved and comes with a lot of trade-offs but if nobody starts the discussion, we'll just go nowhere. All the points you raised are perfectly valid, and needs to be discussed with every stakeholder. Maybe the final solution will be completely different, but that's not what matters. This is a concrete way to build Fedora/CentOS collaboration.
If merging cost is too important, then we could discuss alternatives (like EPEL rebuilds automation in CBS), but we need to end the discussion at some point. Anyway, I won't champion any proposal that gets no support from both communities.
Well, personally, I'd like to hear why less difficult methods wont work:
1. Just enable EPEL repo in CBS? I assume this won't work because people sometimes want to rebuild things? but can't they just make sure they are newer than the EPEL version? or what are the use cases here?
2. Setup a sync script to just import all EPEL builds into CBS. Then they are full builds just like they were done there, and can be untagged/tagged/etc.
I guess I don't have enough data about the use cases that are pressing here.
kevin
On Monday, September 21, 2015 08:58:21 PM Haïkel wrote:
2015-09-21 19:46 GMT+02:00 Kevin Fenzi kevin@scrye.com:
On Mon, 21 Sep 2015 16:12:07 +0200
Haïkel hguemar@fedoraproject.org wrote:
Hi,
Since the CentOS acquihire, there was a lot of discussion about EPEL's future. Since the FOSDEM meetup between Fedora/CentOS folks, there was little progress on that topic
After a discussion with a Smooge, I decided to come with a proposal, knowing that
- Fedora wants to keep EPEL within it umbrella
- That CentOS SIGs are in practice rebuilding a lot of EPEL packages
(or retag them for other SIGs) leading to poor maintenance as they don't follow EPEL tickets for all their dependencies.
Why is this? would it be enough that the CBS had epel as an external repo that can be added to SIG's projects? that way epel and updates can be available to build against.
Which tickets do you mean here? They are only rebuilding some packages, but not others or?
Any tickets filed against EPEL, for instance, if a bug or CVE is fixed against EPEL package, CBS rebuilds won't be impacted as there's no way to automate that. Some examples from CentOS Cloud SIG:
- RabbitMQ: it's a runtime requirement for OpenStack, we could just
reuse EPEL packages but that would mean that Cloud SIG repository wouldn't be self-contained => Nick Coghlan's RepoFunnel would be a solution to mash repositories here.
- A hell lot of python build requirements, that have to be rebuilt in
CBS, as CBS don't have access to EPEL packages.
if we build and track in epel and use epel in CBS to build against we should be covered.
For instance, if the EPEL package gets fixed for a CVE, the CBS package may not get fixed (and vice-versa). Moreover, it makes mixing EPEL and CentOS SIGs repositories harder.
- EPEL is not part CentOS plans, and as soon as SIGs will progress,
*may* turn the former irrelevant
I suppose, but lots of people use/look to epel for packages, I don't think that will change to using packages from CentOS sigs overnight.
I agree.
- Some EPEL packages are poorly maintained especially on older EL
releases and/or orphaned
Sure, just like any large collection of packages.
Yes, but all the more a reason to make it easier for CentOS community to participate to this efforts
I am all for making it easier to contribute to EPEL, one thing to consider is that to contribute to EPEL you must agree to the FPCA, afaik CentOS does not have an equivalent and at the least Legal requires it for Fedora and EPEL
We've reached the point where both EPEL/CBS would greatly benefit to join hands.
So I suggest that we consider the following:
- EPEL will still use Fedora dist-git
- EPEL builds should be done in CBS to make it easier for SIGs to
consume it.
How do EPEL maintainers launch builds in CBS?
Through bstrinson centpkg tool as for the tooling aspect (infra-related issues are covered in a later point)
why would it need to if we are using fedora's dist-git? It seems very very messy here.
How do builds get signed?
That would be left to CentOS core SIG team
Okay, I would like to know what exactly that means and entails, for one we have no way to export the private keys for epel from Fedora's sigul server. changing keys would be a pain and require a lot of careful work.
How do updates get pushed out to EPEL users? Does CentOS have a bodhi
Good question, from my current experience, I get little feedback on my EPEL updates and never got one pushed to stable just through karma.
So what can we do to add extra QA and testing? as that is what is needed to get builds pushed via karma. I do not see that magically being fixed.
instance?
- EPEL will use CentOS repositories instead of mirroring RHEL
repositories
CBS seems to not have ppc64... so no more ppc64 EPEL packages?
True, if we could get some stats over ppc64 (and any arch unsupported by CentOS), that would help weighting on the decision as for any trade-off.
We are talking about adding ppc64le aarch64 and possibly s390x to epel. there is also the issue that will creap up because of the differences in how RHEL and CentOS ship that packages from EPEL will not be installable on RHEL when build on CentOS. This is a RHEL issue, but it is nicer to track by building against REHL and not CentOS, though we also discussed having i686 builds that use CentOS to build against
Also, this would probibly be some kind of big deal to some people who like that EPEL is built against rhel. Personally, I don't think it matters, but it would have to be communicated clearly.
(I also saw Karsten reply about it) It needs to be communicated, but considering CentOS good history on that matter, I personally don't think it's big deal, too.
It is a much bigger deal politically than technically
- Bridging Fedora/CentOS accounting system (CentOS is migrating to
FAS) <== we need to see the feasibility of this but that would be optimal, that would increase the permeability between our two contributors pools which is something, we all want to encourage.
Bridging in which way? what information would be good to communicate back and forth?
I'm not familiar enough with the FAS/pkgdb architecture, so I will just list some requirements.
- ensure that EPEL packagers could rebuild their packages in CBS
- ensure that CentOS core SIG could administrate epel-provenpackager group
Off course, it could be minimal and may not require syncing FAS instances, in the end.
I would like to know what you mean here and what you are thinking, regardless of if its technically possibly today or not. It may be possible in the future.
- Create a EPEL provenpackager group under CentOS core SIG
supervision, allowing them to appoint people to maintain EPEL packages.
Overriding the existing EPEL maintainers?
Yes, as provenpackager could do with most Fedora packages but limited to EPEL branches. I know this may be difficult to give some control to another organization over part of our project. But we need to consider that Fedora/CentOS are part of a larger ecosystem.
This should be implementable.
I suggest that we keep the EPEL name to acknowledge EPEL historical effort to provide quality additional packages for EL distros. Fedora contributors would still be able to contribute to EPEL, and CentOS contributors to make it up their standards.
Would that work for you?
I think there would be a large amount of technical and public relations work needed to get anything like this off the ground.
If the problem is that CBS only has a subset of epel builds, perhaps we could solve that by setting up a script that listens to fedora fedmsgs and imports epel builds from fedora koji when they are done?
kevin
Yes, my first proposal may have sounded that it's trivial but it's not. On the other hand, this is something achievable and that could benefit for both projects.
As any proposal, this needs to be discussed, improved and comes with a lot of trade-offs but if nobody starts the discussion, we'll just go nowhere. All the points you raised are perfectly valid, and needs to be discussed with every stakeholder. Maybe the final solution will be completely different, but that's not what matters. This is a concrete way to build Fedora/CentOS collaboration.
If merging cost is too important, then we could discuss alternatives (like EPEL rebuilds automation in CBS), but we need to end the discussion at some point. Anyway, I won't champion any proposal that gets no support from both communities.
There is a massive amount of political play here. it is not trivial technically or politically. I am all for working out ways to enable CentOS contributors to contribute to EPEL. I personally do not think that moving to CBS solves any problems, but will create many. I do not know where CBS is physically located, but if it was in the same data centre as Fedora's koji maybe we could look at sharing some resources, storage and database for koji, while providing separate frontends and views in. though Fedora is at about 30T of disk right now, not sure where CentOS is and how much we would need, but I am guessing in the order of 60T or more.
I think that shorter term, CentOS needs to allow epel to be used as an external repo, and we need to come up with ways to make it easier for people that have traditionally worked in CentOS to contribute to EPEL.
Dennis
2015-09-22 21:18 GMT+02:00 Dennis Gilmore dennis@ausil.us:
On Monday, September 21, 2015 08:58:21 PM Haïkel wrote:
2015-09-21 19:46 GMT+02:00 Kevin Fenzi kevin@scrye.com:
On Mon, 21 Sep 2015 16:12:07 +0200
Haïkel hguemar@fedoraproject.org wrote:
Hi,
Since the CentOS acquihire, there was a lot of discussion about EPEL's future. Since the FOSDEM meetup between Fedora/CentOS folks, there was little progress on that topic
After a discussion with a Smooge, I decided to come with a proposal, knowing that
- Fedora wants to keep EPEL within it umbrella
- That CentOS SIGs are in practice rebuilding a lot of EPEL packages
(or retag them for other SIGs) leading to poor maintenance as they don't follow EPEL tickets for all their dependencies.
Why is this? would it be enough that the CBS had epel as an external repo that can be added to SIG's projects? that way epel and updates can be available to build against.
Well, that was my first idea, but it ended up in dead-end, both EPEL and CentOS have their arguments. This situation is no good for both projects, I tried to revive the discussion through a proposal.
The point itself is not the proposal but to solve the problem that there is no integrated vision between EPEL/CentOS.
Which tickets do you mean here? They are only rebuilding some packages, but not others or?
Any tickets filed against EPEL, for instance, if a bug or CVE is fixed against EPEL package, CBS rebuilds won't be impacted as there's no way to automate that. Some examples from CentOS Cloud SIG:
- RabbitMQ: it's a runtime requirement for OpenStack, we could just
reuse EPEL packages but that would mean that Cloud SIG repository wouldn't be self-contained => Nick Coghlan's RepoFunnel would be a solution to mash repositories here.
- A hell lot of python build requirements, that have to be rebuilt in
CBS, as CBS don't have access to EPEL packages.
if we build and track in epel and use epel in CBS to build against we should be covered.
For instance, if the EPEL package gets fixed for a CVE, the CBS package may not get fixed (and vice-versa). Moreover, it makes mixing EPEL and CentOS SIGs repositories harder.
- EPEL is not part CentOS plans, and as soon as SIGs will progress,
*may* turn the former irrelevant
I suppose, but lots of people use/look to epel for packages, I don't think that will change to using packages from CentOS sigs overnight.
I agree.
- Some EPEL packages are poorly maintained especially on older EL
releases and/or orphaned
Sure, just like any large collection of packages.
Yes, but all the more a reason to make it easier for CentOS community to participate to this efforts
I am all for making it easier to contribute to EPEL, one thing to consider is that to contribute to EPEL you must agree to the FPCA, afaik CentOS does not have an equivalent and at the least Legal requires it for Fedora and EPEL
We've reached the point where both EPEL/CBS would greatly benefit to join hands.
So I suggest that we consider the following:
- EPEL will still use Fedora dist-git
- EPEL builds should be done in CBS to make it easier for SIGs to
consume it.
How do EPEL maintainers launch builds in CBS?
Through bstrinson centpkg tool as for the tooling aspect (infra-related issues are covered in a later point)
why would it need to if we are using fedora's dist-git? It seems very very messy here.
How do builds get signed?
That would be left to CentOS core SIG team
Okay, I would like to know what exactly that means and entails, for one we have no way to export the private keys for epel from Fedora's sigul server. changing keys would be a pain and require a lot of careful work.
How do updates get pushed out to EPEL users? Does CentOS have a bodhi
Good question, from my current experience, I get little feedback on my EPEL updates and never got one pushed to stable just through karma.
So what can we do to add extra QA and testing? as that is what is needed to get builds pushed via karma. I do not see that magically being fixed.
instance?
- EPEL will use CentOS repositories instead of mirroring RHEL
repositories
CBS seems to not have ppc64... so no more ppc64 EPEL packages?
True, if we could get some stats over ppc64 (and any arch unsupported by CentOS), that would help weighting on the decision as for any trade-off.
We are talking about adding ppc64le aarch64 and possibly s390x to epel. there is also the issue that will creap up because of the differences in how RHEL and CentOS ship that packages from EPEL will not be installable on RHEL when build on CentOS. This is a RHEL issue, but it is nicer to track by building against REHL and not CentOS, though we also discussed having i686 builds that use CentOS to build against
Architecture-wise, I believe there are similar plans from CentOS sides (Jim is actively working on aarch64 port and power port is in discusion) Ack for the RHEL/CentOS differences.
Also, this would probibly be some kind of big deal to some people who like that EPEL is built against rhel. Personally, I don't think it matters, but it would have to be communicated clearly.
(I also saw Karsten reply about it) It needs to be communicated, but considering CentOS good history on that matter, I personally don't think it's big deal, too.
It is a much bigger deal politically than technically
- Bridging Fedora/CentOS accounting system (CentOS is migrating to
FAS) <== we need to see the feasibility of this but that would be optimal, that would increase the permeability between our two contributors pools which is something, we all want to encourage.
Bridging in which way? what information would be good to communicate back and forth?
I'm not familiar enough with the FAS/pkgdb architecture, so I will just list some requirements.
- ensure that EPEL packagers could rebuild their packages in CBS
- ensure that CentOS core SIG could administrate epel-provenpackager group
Off course, it could be minimal and may not require syncing FAS instances, in the end.
I would like to know what you mean here and what you are thinking, regardless of if its technically possibly today or not. It may be possible in the future.
Ideally identity management federation, we should able Fedora account with CentOS infrastructure, by granting proper ACLs and vice-versa. But if that confuses people, let's drop it.
- Create a EPEL provenpackager group under CentOS core SIG
supervision, allowing them to appoint people to maintain EPEL packages.
Overriding the existing EPEL maintainers?
Yes, as provenpackager could do with most Fedora packages but limited to EPEL branches. I know this may be difficult to give some control to another organization over part of our project. But we need to consider that Fedora/CentOS are part of a larger ecosystem.
This should be implementable.
Yes!
I suggest that we keep the EPEL name to acknowledge EPEL historical effort to provide quality additional packages for EL distros. Fedora contributors would still be able to contribute to EPEL, and CentOS contributors to make it up their standards.
Would that work for you?
I think there would be a large amount of technical and public relations work needed to get anything like this off the ground.
If the problem is that CBS only has a subset of epel builds, perhaps we could solve that by setting up a script that listens to fedora fedmsgs and imports epel builds from fedora koji when they are done?
kevin
Yes, my first proposal may have sounded that it's trivial but it's not. On the other hand, this is something achievable and that could benefit for both projects.
As any proposal, this needs to be discussed, improved and comes with a lot of trade-offs but if nobody starts the discussion, we'll just go nowhere. All the points you raised are perfectly valid, and needs to be discussed with every stakeholder. Maybe the final solution will be completely different, but that's not what matters. This is a concrete way to build Fedora/CentOS collaboration.
If merging cost is too important, then we could discuss alternatives (like EPEL rebuilds automation in CBS), but we need to end the discussion at some point. Anyway, I won't champion any proposal that gets no support from both communities.
There is a massive amount of political play here. it is not trivial technically or politically. I am all for working out ways to enable CentOS contributors to contribute to EPEL. I personally do not think that moving to CBS solves any problems, but will create many. I do not know where CBS is physically located, but if it was in the same data centre as Fedora's koji maybe we could look at sharing some resources, storage and database for koji, while providing separate frontends and views in. though Fedora is at about 30T of disk right now, not sure where CentOS is and how much we would need, but I am guessing in the order of 60T or more.
There is a technical cost to such migration, but I agree that the biggest blocker is political play (from both sides) It maybe naive from me, but I'd like us stop thinking as Fedora/EPEL/CentOS as silos but rather as an integrated ecosystem. Different target, different usage but same DNA.
I think that shorter term, CentOS needs to allow epel to be used as an external repo, and we need to come up with ways to make it easier for people that have traditionally worked in CentOS to contribute to EPEL.
Dennis
That makes sense, but we never reached to an agreement, even a minimal one.
From my perspective as CentOS SIG member, it's preventing us to grow
healthily as we're relying on random EPEL rebuilds: maybe modified, maybe not updated. In the end, it will end up having CentOS rebuilding EPEL from scratch which means duplicated efforts.
What's important is that we move forward on a topic discussed for almost two years, not the proposal itself.
H.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/22/2015 12:18 PM, Dennis Gilmore wrote:
Also, this would probibly be some kind of big deal to some people who like that EPEL is built against rhel. Personally, I don't think it matters, but it would have to be communicated clearly.
(I also saw Karsten reply about it) It needs to be communicated, but considering CentOS good history on that matter, I personally don't think it's big deal, too.
It is a much bigger deal politically than technically
I agree it's a big deal, but think it's more about 'supportability', which is the crossroads for technical, end-user needs, business dynamics, community capability, and so forth.
I personally *like* that Red Hat support has comfort level with pointing customers at EPEL; I don't want that to change. To me that is a core promise from the community to our end-users, wherever they are from.
- - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
On Tuesday, September 22, 2015 07:21:16 PM Karsten Wade wrote:
On 09/22/2015 12:18 PM, Dennis Gilmore wrote:
Also, this would probibly be some kind of big deal to some people who like that EPEL is built against rhel. Personally, I don't think it matters, but it would have to be communicated clearly.
(I also saw Karsten reply about it) It needs to be communicated, but considering CentOS good history on that matter, I personally don't think it's big deal, too.
It is a much bigger deal politically than technically
I agree it's a big deal, but think it's more about 'supportability', which is the crossroads for technical, end-user needs, business dynamics, community capability, and so forth.
I personally *like* that Red Hat support has comfort level with pointing customers at EPEL; I don't want that to change. To me that is a core promise from the community to our end-users, wherever they are from.
Completely agree, It is a change I would not really be comfortable making. Some of the politics around it comes from Sales guys in Red Hat and support people in Red Hat being comfortable saying go use EPEL, and they likely would not be if it was built against CentOS. But I do not want to rule it out entirely and if we build i686 for epel7 it will have to be built against CentOS for i686
Dennis
On Sep 21 20:58, Haïkel wrote:
2015-09-21 19:46 GMT+02:00 Kevin Fenzi kevin@scrye.com:
On Mon, 21 Sep 2015 16:12:07 +0200 Haïkel hguemar@fedoraproject.org wrote:
Hi,
Since the CentOS acquihire, there was a lot of discussion about EPEL's future. Since the FOSDEM meetup between Fedora/CentOS folks, there was little progress on that topic
After a discussion with a Smooge, I decided to come with a proposal, knowing that
- Fedora wants to keep EPEL within it umbrella
- That CentOS SIGs are in practice rebuilding a lot of EPEL packages
(or retag them for other SIGs) leading to poor maintenance as they don't follow EPEL tickets for all their dependencies.
+1000 this is definitely one of the more bumpy experiences of the SIG process.
Which tickets do you mean here? They are only rebuilding some packages, but not others or?
Any tickets filed against EPEL, for instance, if a bug or CVE is fixed against EPEL package, CBS rebuilds won't be impacted as there's no way to automate that. Some examples from CentOS Cloud SIG:
- RabbitMQ: it's a runtime requirement for OpenStack, we could just
reuse EPEL packages but that would mean that Cloud SIG repository wouldn't be self-contained => Nick Coghlan's RepoFunnel would be a solution to mash repositories here.
- A hell lot of python build requirements, that have to be rebuilt in
CBS, as CBS don't have access to EPEL packages.
For instance, if the EPEL package gets fixed for a CVE, the CBS package may not get fixed (and vice-versa). Moreover, it makes mixing EPEL and CentOS SIGs repositories harder.
I'd rather see this happen through automation. If we're maintaining a "cbs-common" repo (as Fabian and others are speaking of down-thread), it would be simple to work out the inclusion/exclusion policy and set things going (I suppose that means I've volunteered myself to help with the tools :). Something like cbs-common has the added benefit of treating EPEL like an "upstream" in that developers are allowed to consume the bits from EPEL while adding in packages from other places, and where they're encouraged to contribute back.
- EPEL is not part CentOS plans, and as soon as SIGs will progress,
*may* turn the former irrelevant
I suppose, but lots of people use/look to epel for packages, I don't think that will change to using packages from CentOS sigs overnight.
I agree.
- Some EPEL packages are poorly maintained especially on older EL
releases and/or orphaned
Sure, just like any large collection of packages.
Yes, but all the more a reason to make it easier for CentOS community to participate to this efforts
Participate yes, but EPEL is a packaging effort that, I think, belongs in a community with a broad base of packagers (Fedora). There are definitely things we can do from both sides to make collaboration more seamless.
...SNIP some technical questions...
- Bridging Fedora/CentOS accounting system (CentOS is migrating to
FAS) <== we need to see the feasibility of this but that would be optimal, that would increase the permeability between our two contributors pools which is something, we all want to encourage.
Bridging in which way? what information would be good to communicate back and forth?
I'm not familiar enough with the FAS/pkgdb architecture, so I will just list some requirements.
- ensure that EPEL packagers could rebuild their packages in CBS
Automation through cbs-common would handle this case
- ensure that CentOS core SIG could administrate epel-provenpackager group
I think we should work up something in EPEL for this. We started an "epel-wranglers" group in EPEL-land, I think the next step would be to round up EPEL-provenpackagers some of whom would come from the CentOS community.
Off course, it could be minimal and may not require syncing FAS instances, in the end.
Perhaps not syncing FAS instances, but we (CentOS) are hoping to make progress on our auth systems in concert with Fedora and other communities (See the freshly announced Community Auth Working Group).
- Create a EPEL provenpackager group under CentOS core SIG
supervision, allowing them to appoint people to maintain EPEL packages.
Overriding the existing EPEL maintainers?
Yes, as provenpackager could do with most Fedora packages but limited to EPEL branches. I know this may be difficult to give some control to another organization over part of our project. But we need to consider that Fedora/CentOS are part of a larger ecosystem.
I suggest that we keep the EPEL name to acknowledge EPEL historical effort to provide quality additional packages for EL distros. Fedora contributors would still be able to contribute to EPEL, and CentOS contributors to make it up their standards.
Would that work for you?
I think there would be a large amount of technical and public relations work needed to get anything like this off the ground.
If the problem is that CBS only has a subset of epel builds, perhaps we could solve that by setting up a script that listens to fedora fedmsgs and imports epel builds from fedora koji when they are done?
kevin
Yes, my first proposal may have sounded that it's trivial but it's not. On the other hand, this is something achievable and that could benefit for both projects.
As any proposal, this needs to be discussed, improved and comes with a lot of trade-offs but if nobody starts the discussion, we'll just go nowhere. All the points you raised are perfectly valid, and needs to be discussed with every stakeholder. Maybe the final solution will be completely different, but that's not what matters. This is a concrete way to build Fedora/CentOS collaboration.
If merging cost is too important, then we could discuss alternatives (like EPEL rebuilds automation in CBS), but we need to end the discussion at some point. Anyway, I won't champion any proposal that gets no support from both communities.
Regards, H.
Thanks for bringing this up, it definitely helps 1.) to bring up old points of discussion that have become a bit stale, and 2.) highlight some of the pain points from the point of view of an experienced SIG member.
Cheers! --Brian
On 09/21/2015 07:42 PM, Haïkel wrote:
Hi,
Since the CentOS acquihire, there was a lot of discussion about EPEL's future. Since the FOSDEM meetup between Fedora/CentOS folks, there was little progress on that topic
After a discussion with a Smooge, I decided to come with a proposal, knowing that
- Fedora wants to keep EPEL within it umbrella
- That CentOS SIGs are in practice rebuilding a lot of EPEL packages
(or retag them for other SIGs) leading to poor maintenance as they don't follow EPEL tickets for all their dependencies. 3. EPEL is not part CentOS plans, and as soon as SIGs will progress, *may* turn the former irrelevant 4. Some EPEL packages are poorly maintained especially on older EL releases and/or orphaned
We've reached the point where both EPEL/CBS would greatly benefit to join hands.
So I suggest that we consider the following:
- EPEL will still use Fedora dist-git
- EPEL builds should be done in CBS to make it easier for SIGs to consume it.
- EPEL will use CentOS repositories instead of mirroring RHEL repositories
- Bridging Fedora/CentOS accounting system (CentOS is migrating to
FAS) <== we need to see the feasibility of this but that would be optimal, that would increase the permeability between our two contributors pools which is something, we all want to encourage.
- Create a EPEL provenpackager group under CentOS core SIG
supervision, allowing them to appoint people to maintain EPEL packages.
I suggest that we keep the EPEL name to acknowledge EPEL historical effort to provide quality additional packages for EL distros. Fedora contributors would still be able to contribute to EPEL, and CentOS contributors to make it up their standards.
Would that work for you?
+1. I liked the idea. It would save a lots of repeated efforts for building similar packages in CBS for SIGs.
I think we should we settle EPEL vs SIG stuff asap. Because this will help SIG and EPEL to grow and stay relevant.
Thanks, Lala
Regards, H. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Le 21/09/2015 16:12, Haïkel a écrit :
Hi,
Since the CentOS acquihire, there was a lot of discussion about EPEL's future. Since the FOSDEM meetup between Fedora/CentOS folks, there was little progress on that topic
Just enable EPEL in CBS, and that's all.
Remi.
P.S. and explain to SIG member how to contribute to EPEL.
On Tue, Sep 22, 2015 at 6:56 AM, Remi Collet Fedora@famillecollet.com wrote:
Le 21/09/2015 16:12, Haïkel a écrit :
Hi,
Since the CentOS acquihire, there was a lot of discussion about EPEL's
future.
Since the FOSDEM meetup between Fedora/CentOS folks, there was little progress on that topic
Just enable EPEL in CBS, and that's all.
Remi.
P.S. and explain to SIG member how to contribute to EPEL.
+1. I agree that using EPEL rather than trying to replace it is a much better solution.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/22/2015 11:35 AM, Dave Johansen wrote:
On Tue, Sep 22, 2015 at 6:56 AM, Remi Collet Fedora@famillecollet.com wrote:
Le 21/09/2015 16:12, Haïkel a écrit :
Hi,
Since the CentOS acquihire, there was a lot of discussion about EPEL's
future.
Since the FOSDEM meetup between Fedora/CentOS folks, there was little progress on that topic
Just enable EPEL in CBS, and that's all.
Remi.
P.S. and explain to SIG member how to contribute to EPEL.
+1. I agree that using EPEL rather than trying to replace it is a much better solution.
AIUI, the concern is that what is labeled/supported by the CentOS Project as 'CentOS' needs to go through the CentOS Project QA system. We simply cannot blindly accept builds from outside of the CentOS builders just on say-so. (Compare to RPMfusion et al -- putting that repo in as a default for Fedora users is more than a legal issue, it's a QA/test/build/sign/release issue.)
Two possible pathways from there are:
1. Rebuild all of EPEL in cbs.centos.org for SIGs to use; make it available as an alternate repo (of just rebuilt packages); encourage people to choose EPEL otherwise without an associated QA endorsement.
2. Figure out how to test EPEL 100% against CentOS (such as Fedora's Koji builds EPEL against CentOS and runs all latest CentOS Project QA before signing and shipping.)
On the latter, I only have an indication that might work -- I defer to the CentOS and EPEL experts to figure out the technical how-to. :) But once they are done & happy, I'd then be happy to sign-off on calling the result 'CentOS'.
Regards,
- - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
On Tuesday, September 22, 2015 08:45:32 PM Karsten Wade wrote:
On 09/22/2015 11:35 AM, Dave Johansen wrote:
On Tue, Sep 22, 2015 at 6:56 AM, Remi Collet
Fedora@famillecollet.com wrote:
Le 21/09/2015 16:12, Haïkel a écrit :
Hi,
Since the CentOS acquihire, there was a lot of discussion about EPEL's
future.
Since the FOSDEM meetup between Fedora/CentOS folks, there was little progress on that topic
Just enable EPEL in CBS, and that's all.
Remi.
P.S. and explain to SIG member how to contribute to EPEL.
+1. I agree that using EPEL rather than trying to replace it is a much better solution.
AIUI, the concern is that what is labeled/supported by the CentOS Project as 'CentOS' needs to go through the CentOS Project QA system. We simply cannot blindly accept builds from outside of the CentOS builders just on say-so. (Compare to RPMfusion et al -- putting that repo in as a default for Fedora users is more than a legal issue, it's a QA/test/build/sign/release issue.)
I disagree here, it is entirely a legal issue, if there were not the legal issue to deal with then the packages would be in Fedora and the rest is taken care of.
Two possible pathways from there are:
- Rebuild all of EPEL in cbs.centos.org for SIGs to use; make it
available as an alternate repo (of just rebuilt packages); encourage people to choose EPEL otherwise without an associated QA endorsement.
This seems wasteful, but is an option.
- Figure out how to test EPEL 100% against CentOS (such as Fedora's
Koji builds EPEL against CentOS and runs all latest CentOS Project QA before signing and shipping.)
We are unlikely to build EPEL against CentOS except for arches not supported by Red Hat (i686 today). But we should be able to setup tests in taskotron that test against CentOS as well as against RHEL. that is something I could fully support.
On the latter, I only have an indication that might work -- I defer to the CentOS and EPEL experts to figure out the technical how-to. :) But once they are done & happy, I'd then be happy to sign-off on calling the result 'CentOS'.
We would need to engage the QA team to see what we can do in taskotron exactly
Dennis
On Tue, Sep 22, 2015 at 08:45:32PM -0700, Karsten Wade wrote:
AIUI, the concern is that what is labeled/supported by the CentOS Project as 'CentOS' needs to go through the CentOS Project QA system. We simply cannot blindly accept builds from outside of the CentOS builders just on say-so. (Compare to RPMfusion et al -- putting that repo in as a default for Fedora users is more than a legal issue, it's a QA/test/build/sign/release issue.)
I can understand that with "out of the family" sources, but with Red Hat now sponsoring CentOS as well as Fedora.... can we build a better bridge of trust, here?
On 23 September 2015 at 10:31, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Sep 22, 2015 at 08:45:32PM -0700, Karsten Wade wrote:
AIUI, the concern is that what is labeled/supported by the CentOS Project as 'CentOS' needs to go through the CentOS Project QA system. We simply cannot blindly accept builds from outside of the CentOS builders just on say-so. (Compare to RPMfusion et al -- putting that repo in as a default for Fedora users is more than a legal issue, it's a QA/test/build/sign/release issue.)
I can understand that with "out of the family" sources, but with Red Hat now sponsoring CentOS as well as Fedora.... can we build a better bridge of trust, here?
I thought what Karsten was asking for was "Trust but Verify". They aren't going to blindly trust RPMs for CentOS more than we are going to blindly trust RPMs from COPRs in the build system {I think Copr is a better analogy than RPMfusion as that gets covered in legal sauce.}. The packages need some sort of testing which would actually be more than what we have currently in EPEL. {ssssh I didn't say this.}
There are multiple ways they can trust but verify. * Rebuild the package in the CBS system and get their CI to run tests as part of that. * Run the CI against the packages which depending on how the CI is intertwined with Koji may be harder than it sounds. * Help get a similar CI stood up for EPEL and trust those results.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/23/2015 09:49 AM, Stephen John Smoogen wrote:
On 23 September 2015 at 10:31, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Sep 22, 2015 at 08:45:32PM -0700, Karsten Wade wrote:
AIUI, the concern is that what is labeled/supported by the CentOS Project as 'CentOS' needs to go through the CentOS Project QA system. We simply cannot blindly accept builds from outside of the CentOS builders just on say-so. (Compare to RPMfusion et al -- putting that repo in as a default for Fedora users is more than a legal issue, it's a QA/test/build/sign/release issue.)
I can understand that with "out of the family" sources, but with Red Hat now sponsoring CentOS as well as Fedora.... can we build a better bridge of trust, here?
I thought what Karsten was asking for was "Trust but Verify". They aren't going to blindly trust RPMs for CentOS more than we are going to blindly trust RPMs from COPRs in the build system {I think Copr is a better analogy than RPMfusion as that gets covered in legal sauce.}. The packages need some sort of testing which would actually be more than what we have currently in EPEL. {ssssh I didn't say this.}
There are multiple ways they can trust but verify. * Rebuild the package in the CBS system and get their CI to run tests as part of that. * Run the CI against the packages which depending on how the CI is intertwined with Koji may be harder than it sounds. * Help get a similar CI stood up for EPEL and trust those results.
Thanks, yes, this is an accurate explanation of what I meant to say. :)
I also haven't talked with KB about this in a while, he's out of pocket for the next few weeks, so it may be a bit until we can get his input.
- - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
Looks like we do have some progress on that topic :)
So plan B would be: 1. automate EPEL rebuilds in CBS 2. have CI run automated test suite over EPEL rebuilds
Correct me if I'm wrong but we would be ok to enable CentOS folks to fix EPEL packaging. It would be easier if we do create an epel-provenpackager group limited to EL branches distinct from fedora's provenpackager as in the first proposal.
If that's ok for everyone, let's wait Karsten speak to KB (and hopefully, start working on this asap)
H.
On 24 September 2015 at 10:40, Haïkel hguemar@fedoraproject.org wrote:
Looks like we do have some progress on that topic :)
So plan B would be:
- automate EPEL rebuilds in CBS
- have CI run automated test suite over EPEL rebuilds
Correct me if I'm wrong but we would be ok to enable CentOS folks to fix EPEL packaging.
That is the 10,000 km view of the items. There is a LOT of detail that is lost at that height. There have to be CentOS people wanting to fix things in EPEL and they would need to get accounts in the Fedora system. There are always people saying they want this, but not a lot who do anything with it. [The reason for them to get a Fedora account is that any sort of federalization built into FAS is a ways out (1-2 years at the rate FAS gets worked on?)]
There will also need to be done on what a proven packager is in EPEL land, and if it is even possible to have an epel-provenpackager which doesn't break fedora-provenpackager and vice versa. That is a lot of work which at the rate things work in CentOS and/or EPEL land is years off.
It would be easier if we do create an epel-provenpackager group limited to EL branches distinct from fedora's provenpackager as in the first proposal.
If that's ok for everyone, let's wait Karsten speak to KB (and hopefully, start working on this asap)
H. _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
2015-09-24 18:58 GMT+02:00 Stephen John Smoogen smooge@gmail.com:
On 24 September 2015 at 10:40, Haïkel hguemar@fedoraproject.org wrote:
Looks like we do have some progress on that topic :)
So plan B would be:
- automate EPEL rebuilds in CBS
- have CI run automated test suite over EPEL rebuilds
Correct me if I'm wrong but we would be ok to enable CentOS folks to fix EPEL packaging.
That is the 10,000 km view of the items. There is a LOT of detail that is lost at that height. There have to be CentOS people wanting to fix things in EPEL and they would need to get accounts in the Fedora system. There are always people saying they want this, but not a lot who do anything with it. [The reason for them to get a Fedora account is that any sort of federalization built into FAS is a ways out (1-2 years at the rate FAS gets worked on?)]
Still an huge improvement compared to the previous dead-end. What matters is that we agree on a common goal and start working toward that.
I implicitly volunteered myself to work on the build automation, as I'm already currently doing a lot of *manual* rebuilds and syncing.
There will also need to be done on what a proven packager is in EPEL land, and if it is even possible to have an epel-provenpackager which doesn't break fedora-provenpackager and vice versa. That is a lot of work which at the rate things work in CentOS and/or EPEL land is years off.
I separated this from the list as it doesn't prevent us to automate EPEL rebuilds + CI, it's more something *nice to have* if we want to make EPEL less foreign to CentOS folks.
From Kevin's answer, it should be possible. I cannot exactly estimate
the task but it's rather a question of months than years.
It would be easier if we do create an epel-provenpackager group limited to EL branches distinct from fedora's provenpackager as in the first proposal.
If that's ok for everyone, let's wait Karsten speak to KB (and hopefully, start working on this asap)
H. _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
-- Stephen J Smoogen. _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
On 22 Sep 2015, at 8:35 PM, Dave Johansen davejohansen@gmail.com wrote:
+1. I agree that using EPEL rather than trying to replace it is a much better solution.
+1 why "fix" something that is not broken
epel-devel@lists.fedoraproject.org
-
Andrew Colin Kissa -
Brian Stinson -
Dave Johansen -
Dennis Gilmore -
Haïkel -
Karsten Wade -
Kevin Fenzi -
Lalatendu Mohanty -
Matthew Miller -
Remi Collet -
Stephen John Smoogen