EPEL EpSCO Email Meeting:

[Jim Perrin]

On 09/04/2014 11:13 AM, Kevin Fenzi wrote:
> On Fri, 29 Aug 2014 16:08:34 -0600
> Stephen John Smoogen <smooge at gmail.com> wrote:
> 
>> So in todays (2014-08-29) meeting, we wanted to move the various
>> policy discussions to email so that people could take their time to
>> reply and also to allow for people who could not attend time to
>> respond.
> 
> Right. 
> 
>> Going from the web-page
>> https://fedoraproject.org/wiki/EPEL-faster-repo-ideas the following
>> items are listed (with additions I added while writing this email.)
>>
>> I would like to start with the EpSCO governance to just get that out
>> of the way and then move to current rules as we see them. I can act
>> as secretary to make sure that changes discussed here are put in
>> place on the wiki or other places.
>>
>> Policy questions
>>
>>    - EpSCO governance.
>>       - Lifetime of initial committee (9 months?)
>>       - Replacement of any exiting members (replacement by formal
>> vote, etc).
>>       - Size of committee (4 members? 5 members?)
>>       - Meeting rules (follow
>>       https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee
>>       )
> 
> I'm happy with whatever other people want. I think making things super
> formal just causes more problems. I think we agreed on 4 members for
> now, we can add by vote of those folks, we should try and meet weekly.
> 

+1 here as well. I don't see a need to make it overly rigid.


>>
>>    - How many repos? (examples below)
>>       - epel,
>>          - epel-test
>>       - epel-rolling
>>          - epel-rolling-test ?
>>       - epel-edge ?
>>          - epel-edge-test ?
> 
> There's some thought from folks about doing a per point release repos. 
> I added some comments asking for more details on that idea. 


Without further info on this, my gut reaction is to NOT do point
releases. I could be persuaded if there's a strong enough benefit.

> If repos we add as fast moving/whatever they may not need/want testing
> repos. 
> 
>>    - What would faster moving mean?
> 
> Good question. Perhaps folks could list out some example packages and
> stacks that aren't happy with epel as it is and we could better come up
> with use cases to help those?


Within the CentOS SIG framework, most of the 'newer' packages would
likely be for things like php, perl, python, libvirt. Example, the ceph
and ovirt teams would both benefit from having a newer libvirt available
to them.


> 
>>
>>    - Would packages in this be able to conflict with epel packages?
>> Base packages?
>  
>>
>>    - When would incompatible changes be allowed in each branch?
>>
>>
>>    - Different guidelines for specs/packages per branch?
> 
> I would REALLY like to avoid this. EPEL leverages the excellent (IMHO)
> Fedora guidelines. If we go off and do our own thing we are doing our
> users a disservice. 
> 

While this is true, look at what happened with puppet for EL6 as an
example. EPEL couldn't move beyond 2.6 to avoid compatibility changes,
but that introduced some security issues in addition to the usual user
cries for current/recent versions.



Perhaps this is an issue where a shorter life-cycle expectation needs to
be set?


>>    - When would a package be expired or removed?
>>
>>
>>    - What are the rules for EPEL packages currently?
> 
> All Fedora guidelines +  https://fedoraproject.org/wiki/EPEL:Packaging
>>
>>    - Currently packages require of 2 weeks in EPEL-testing before
>> promotion to EPEL.
>>       - Can this be changed to 1 week?
> 
> I guess I'd be ok moving it to a week. 


I'd be okay with this as well, especially if there's automated testing
scripts provided

>>       - What Constant Integration would be needed to give auto-karma?
>>
>>
>>    - How to integrate packages shepherded by CentOS (or other SIGS)
>> which may conflict with EPEL packages?
> 


This is a good question. We need to look at both the technical and
policy guidelines around this.




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