EPEL Notes from .next discussion.

[Jim Perrin]

On 08/13/2014 09:23 AM, Kevin Fenzi wrote:
> On Tue, 12 Aug 2014 21:05:07 +0200
> Stephen John Smoogen <smooge at gmail.com> wrote:
> 
>> At FLOCK this year, I did a short workshop on what was labeled
>> EPEL.Next. At that we went over a bit of what EPEL has done in the
>> past, what its current challenges are, and what could be its future.
>> Toshio Kuratomi was great in capturing what was said at the meeting
>> and
> 
> ...snip...
> 
>> For CENTOS7: the epel repofile will be shipped directly with centos
>> for the first time.
> 
> Note that this will be in centos-extras (but thats enabled by default,
> so just a nitpick)
> 
> ...snip...
> 
>> Where are we going?
>> Pain Points:
>> * Inability to yum downgrade because only include one old package in
>> the updates tree
> 
> Yeah, there were some recent mash patches that might help here.
> Allowing us to keep 1 or 2 older ones too. 
> 
> ...snip lots of problems... 
> 
>> Ideas to deal with Pain
>> * Get RHEL licenses for contributors.  There is a process but it
>> takes a long while because of the tax problems for giving it to
>> people.  Current procedure is that we get requests, we give the names
>> to a person inside of RH and then they eventually get back to us with
>> licenses.
> 
> We are working to revamp/improve this. 
> 
>> * Let's create EPIC: separate repo. 3 year lifespan instead of 10
>> year, rhel life cycle.
>> * Debian Volatile repository and also Debian Backports.  These repos
>> contain newer versions of packages, even for Debian Stable.  Good for
>> packages which change all the time.
>> * Debian also has protection mechanism that says no major or no
>> major.minor version updates in apt (their yum equivalent).
>> * Red Hat already releases different lifecycle repositories (layered
>> products).  Why not replicate what they do.
>> * What about implementing EPEL as a set of projects like Fedora
>> Playground?
>>   * Would change the guarantees and expectations of EPEL *quite* a
>> bit.
>>   * Maybe as the way to implement EPIC rather than EPEL.
> 
> I think we really do need to look at another repo for things that are
> so rapid. It's going to be very hard to change user expectations for
> EPEL now, since it's already entrenched. 

I don't think these two options are exclusive.

A second repository would certainly help keep original expectations of
epel in place, and is a good idea.

EPEL itself still provides a base for many projects, and could improve
upon existing user expectations.

> I guess for my uses the parallel installable stuff works fine. I know
> thats not the case for others though, so a more rapidly moving repo
> would be better for them. I wonder if it wouldn't be good to coordinate
> with CentOS folks and see where such a repo would make the most sense? 

I certainly think we should do this. It would benefit both our SIG
communities as well as other interested users.


> The idea of having a release tree was an interesting one. However, it's
> going to be a lot more work. If we are saying "here's EPEL 7.0 release
> repo" we would need to make sure it's well tested and has no issues.
> ie, we would need to go through much of what Fedora does for a release. 
> Do we have any QA folks at all? ;) 

I believe there's an effort for common QA underway. This would be an
area where we (CentOS and Fedora/EPEL) could coordinate.

> I think more practical might be the idea of shipping multiple old
> versions in the existing repos. 
> 
>> * Formalize the governance of EPEL.
>>   * Written policies of some sort for decision making
>>   * Elections?
>>   * Problems to solve:
>>     * Don't want to just listen to the people who are loudest
>>     * Don't want to just listen to the people who have been around the
>> longest
> 
> I'd prefer to avoid voting.... those that do the work should have the
> most input. Or perhaps those that show up. ;) There was some talk about
> trying to do meetings again. I gave up in dispair last time I tried,
> but would happily attend if someone else wants to organize them. 
> 
>> * Do we want automated testing of EPEL?  yes.  get it working on
>> whatever subset you can and we'll go on from there.
> 
> Yeah, I would love some automated testing. 

This should be possible in the reasonably near future.


> 
>> * Move to CentOS as build system?  Gives us additional arches.
> 
> Yeah, if they do a 32bit x86 and 32bit arm, that would give us more
> arches. 

32bit x86 is definitely happening. I'm not certain about 32bit arm,
largely because of the largely varied hardware support requirements and
uboot.

64bit arm(uefi backed) is certainly on our roadmap.



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