On Mon, Jun 4, 2018 at 6:52 AM Sandro Bonazzola <sbonazzo at redhat.com> wrote: > > > 2018-06-04 12:47 GMT+02:00 Alan Pevec <apevec at redhat.com>: > >> > That means that either Brian or me would like to also rebuild (that's >> > the easy part) ansible through CBS, but sticking to the ansible engine >> > version, so rebuilding the src.rpm available here : >> > ftp://ftp.redhat.com/redhat/linux/enterprise/7Server/en/Ansible/SRPMS/ >> >> We could have separate tags and repos, one for .el7ae and the other >> for upstream .el7.ans rebuilds. >> Concern with .el7ae is that there will always be delay and it's up to >> Red Hat product management which versions are selected. >> For OpenStack master CI we'll need to track upstream closely, >> eventually doing per commit cross-project CI, see background >> inhttps://lists.rdoproject.org/pipermail/dev/2018-April/008652.html > > > Agreed, for oVirt is important too having access to latest upstream. > For anyone not paying close attention: The "latest upstream" from RHEL in the "extras" channel is a 2.4 release, the "latest upstream" from EPEL is 2.5. This is going to continue to cause update confusion depending on which non-default channel is activated. If you want the "latest upstream" from ansible source for ovirt, you need the EPEL version, not the RHEL extras version. I realize it's late, but would it make sense to start publishing "ansible24", "ansible25", etc. to avoid these conflicts? Similar work was done for RT, Berkeley DB, gcc, and openssl in the past. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20180606/0108bfec/attachment-0006.html>