On 03/21/2014 11:49 AM, Sam Kottler wrote:
>
>
> ----- Original Message -----
>> From: "Peter Lemenkov" <lemenkov@gmail.com>
>> To: "EPEL Development List" <epel-devel@lists.fedoraproject.org>
>> Cc: rbergero@fedoraproject.org
>> Sent: Friday, March 21, 2014 6:25:50 PM
>> Subject: Re: EPEL EPIC! [was Re: and SCL]
>>
>> 2014-03-21 16:07 GMT+04:00 Matthew Miller <mattdm@fedoraproject.org>:
>>
>>>> It doesn't exist, it's an idea that Robyn has floated semi-seriously
>>>> as a way to provide a repo that moves faster than EPEL. Rather than
>>>> try to jam fast-moving stuff in to EPEL, the idea was to do an Extra
>>>> Packages for Infrastructure and Cloud (EPIC) that had a different,
>>>> faster-moving charter. EPIC would target the *EL platform just as EPEL
>>>> does.
>>
>> Faster moving rate is great indeed. But adding more than on version of
>> software (no matter of how many repos it takes) means only one - we
>> have to impose additional support requiremetns on a packagers.
>>
>> The "social contract" requiremens for EPEL "support" (which of souce
>> isn't a "real" support) is way too high for the average maintainer.
>> That's the reason I believe the entire EPEL idea was a huge mistake
>> and waste of time - unfortunately I failed to discuss this with other
>> fellow fedora members during FOSDEM Fedora.NEXT related talks.
>
> Completely agreed about the issues surrounding maintenance and security backporting. Even upstreams that are supportive of packaging in distros just *can't* support a basically randomly supported of their software for 10 years. EPEL 5 is so neglected at this point, and EPEL 6 is heading that direction because the upstreams simply don't have the manpower to be able to work with the software is packaging a (4|8) year old version of their software. Additionally, most people who run enterprise linux expect ABI/API and upgrade stability so maintainers resort to changing their packages as little as possible. That manifests itself as neglect.
>
> I'd love to see EPIC happen, as I've been telling robyn for the past year and a half :-)

So, lets lay out a couple assumptions and improvements and see where we
end up.

What are the needs and wants for both packagers and users?
What are the lessons to learn from EPEL when creating EPIC?
Does one repository solve this, or would this need to be a project
structure with multiple repositories underneath?