On 8 April 2015 at 18:20, Nico Kadel-Garcia <nkadel@gmail.com> wrote:

On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen <smooge@gmail.com> wrote:
>
>
> On 7 April 2015 at 09:27, Lokesh Mandvekar <lsm5@fedoraproject.org> wrote:
>>
>> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote:
>> > For a long time, Red Hat engineers have dropped public RPMs onto
>> > people.redhat.com. Now that CentOS is a more official part of the family,
>> > it seems like an obvious idea to me, but why not create a "centos7-devel"
>> > branch that is public work that is intended to go into the next upstream
>> > update?
>> >
>> > Several of the existing repos like virt7-testing and atomic7-testing
>> > could simply be folded into this repo.
>>
>> +1, given that packages like docker could be relevant to atomic and virt.
>>
>> >
>> > As well as these "hand built" RPMs:
>> > http://people.redhat.com/lnykryn/systemd/
>> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/
>> >
>> > And I'm sure others.
>>
>> I'd love to see epel get combined with this as well, but I'm probably
>> speaking with a docker-tunneled vision.
>>
>
> I don't think EPEL could fit in here because the audience for EPEL is a lot
> more conservative in what they want than what people working on anything
> from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are
> EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of
> pushback from users when things get updated (this is the reason openstack
> and various other tools have had to been pulled from EPEL in the past..)

That's partly because there are a *lot* of components in EPEL 6 than
are present in EPEL 7. I ran headlong into this trying to build up RT
version 4, the perl dependencies include something like 20 perl module
SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are
available in EPEL 6.

I wish that were the smoking gun, but the growth graphs show that RHEL-5 and RHEL-6 started to grow only after the .2 release was out. At that point the growth begins.

Most of the components are not in EL-7 because maintainers are expected to actively put them into a particular release. We get way more pushback from developers finding out that their package is in an EL without their knowledge than we do from either consumers of EPEL not finding a particular one. [And yes we get a lot of feedback from consumers saying 'why isn't perl-xyz in there when it is in EL-5 and EL-6.]

Stephen J Smoogen.