EPEL EPIC! [was Re: and SCL]

[Jim Perrin]

*bump*

On 03/21/2014 07:43 PM, Stephen John Smoogen wrote:
> On 21 March 2014 16:58, Jim Perrin <jperrin at centos.org> wrote:
> 
>>
>>
>> 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?
>>
>>
> I have a project proposal in my head and need about 48 hours to type it up
> and such. However this weekend is booked solid. If people can wait til
> Wodin's day next week, I should have it done and ready to post. Otherwise I
> can pepper answers to my ideas on Monday/Tuesday.
> 
> <<repotags>>
> 
> 
> 
> 
> _______________________________________________
> epel-devel mailing list
> epel-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/epel-devel
> 

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