On Sep 21 20:58, Haïkel wrote: > 2015-09-21 19:46 GMT+02:00 Kevin Fenzi <kevin at scrye.com>: > > On Mon, 21 Sep 2015 16:12:07 +0200 > > Haïkel <hguemar at 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 > >> 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. +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. > > > >> 3. 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. > > >> 4. 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