[CentOS-devel] [EPEL-devel] [Proposal] Converge EPEL and CBS

[Kevin Fenzi]

On Mon, 21 Sep 2015 20:58:21 +0200
Haïkel <hguemar at fedoraproject.org> wrote:

> 2015-09-21 19:46 GMT+02:00 Kevin Fenzi <kevin at 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20150922/476daf83/attachment.sig>