On 08/13/2014 09:23 AM, Kevin Fenzi wrote:
On Tue, 12 Aug 2014 21:05:07 +0200 Stephen John Smoogen smooge@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.