EPEL EPIC! [was Re: and SCL]

Jim Perrin jperrin at centos.org
Fri Mar 21 22:58:46 UTC 2014



On 03/21/2014 11:49 AM, Sam Kottler wrote:
> 
> 
> ----- Original Message -----
>> From: "Peter Lemenkov" <lemenkov at gmail.com>
>> To: "EPEL Development List" <epel-devel at lists.fedoraproject.org>
>> Cc: rbergero at 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 at 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?



-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77


More information about the epel-devel mailing list